docs(guide): add complex overwrites example

[ST-DDT]

Fixes #1508

• Document how to write factory functions with value overwrites #1508

---

The PR adds an additional example to the complex objects creation documentation.

• Preview

[netlify]

✅ Deploy Preview for fakerjs ready!

Name	Link
🔨 Latest commit	85d8728
🔍 Latest deploy log	https://app.netlify.com/sites/fakerjs/deploys/671663027fe5da0008e85937
😎 Deploy Preview	https://deploy-preview-3207.fakerjs.dev
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 99.96%. Comparing base (f917f4f) to head (85d8728).
Report is 1 commits behind head on next.

Additional details and impacted files

@@           Coverage Diff            @@
##             next    #3207    +/-   ##
========================================
  Coverage   99.95%   99.96%            
========================================
  Files        2798     2798            
  Lines      216718   216718            
  Branches      577      955   +378     
========================================
+ Hits       216631   216642    +11     
+ Misses         87       76    -11     

see 1 file with indirect coverage changes

[matthewmayer]

Hmm this seems more like a "how to use typescript" than anything faker-specific.

[ST-DDT]

The entire section is more about raising awareness of concepts you could use with faker.
The NodeJS-Section explains how you can use faker and the Create Complex Objects section expands on this with ways to structure your methods for complex objects.

A secondary goal is push users into this style of creating "faker" methods, so that they can more easily switch to standalone module functions (see the code examples in the alternatives section) if they would like to when we introduce them in v10.

[xDivisionByZerox]

I'm fine with this, since there was an explicit call out from some community members for this type of documentation.

However, I agree with Matthew that this content seems more related to general programming practices rather than faker specifically. Every programmer should be able to identify these situations as the a requirement for creation design pattern.
Our documentation primarily focuses on the factory pattern. Is it necessary to prime consumers towards a specific programming style, when other approaches, such as the builder pattern, might be better suited for their needs? While it’s not inherently bad, it might limit the flexibility for users to choose the best method for their particular use case.

Furthermore, I fear that the inclusion of documentation that focuses on the developer interaction with faker instead of the usage of faker might set expectations for our community that we don't want to get involved in.

[matthewmayer]

I'll grudgingly approve 😂

Sometimes you see these kind of worked examples in a kind of "cookbook" section. Could be worth considering in future.