Option 2 is almost right.

**An improved option 2**

Create a "front facing" class who's job it is to take that JSON-structure object and pick out the bits and call the factory constructor(s). It takes what the factory makes and gives it to the client. 

- The factory has absolutely no idea that such a JSON thingy even exists.
- The client does not have to know what specific bits the factory needs.

Basically the "front end" is saying to [the 2 Bobs:][1] "I deal with the *redacted* customers so the engineers don't have to! I have people skills!" Poor Tom. If he'd only said "I decouple the client from the construction. This result is a highly cohesive factory"; he might have kept his job.

**Too Many Arguments?**

Not for the client - front end communication.

Front end - factory? If not 10 parameters then the best you can do is put off unpacking, if not the original JSON thing then some DTO. Is this better than passing the JSON to the factory? Same difference I say.

I would strongly consider passing individual parameters. Stick to the goal of a clean, cohesive factory. Avoid the concerns of [@DavidPacker answer.][2]

**Mitigating "too many arguments"**

 - Factory or Class constructors
   - taking only arguments for specific class/object construction.
   - default parameters
   - optional parameters
   - named arguments

 - Front end argument grouping
   - Examines, evaluates, validates, sets, etc. argument values guided by the constructor signatures above.
   


  [1]: https://www.youtube.com/watch?v=RAY27NU1Jog
  [2]: http://programmers.stackexchange.com/a/305315/38663