polyadic method signatures and the Gimmal interview

Shawn Cosby who did my 2018 Gimmal interview asked a lot of elementary basic questions that I am not used to getting asked like "What does a compiler do?" and "What are objects?" Well, rather than having your language be interpreted at runtime and blow up in exception when something is wrong at runtime, some mistakes may be caught upstream by having the runtime language be a language you compile to from another language wherein you write your actual code. If the compiler cannot make a translation from A to B then an error will be thrown at compilation time. There is evidence to suggest that the father upstream you catch an error the less expensive it is in terms of time and heartache to deal with it. (compile time is better than runtime, runtime is better than manual developer passthrough, manual developer passthrough is better than the testing team catching it, the testing team catching it is better than dealing with it in production) Objects are logical collections of primitive types (string, DateTime, Boolean, int, char) or pointers to them into a new type with property names for the various properties (primitives). One of the reasons to have objects in the name of maintainability is to hand objects in at method signatures in lieu of a bunch of individual primitive types. This keeps you from having to constantly change method signatures everywhere use would otherwise use an object that will eventually be updated. Uncle Bob's Clean Code suggests that in the name of utilizing this concept that you should not have polyadic method signatures with four things coming into a signature ideally. That should smell like not using objects. In the Gimmal interview seven was suggested to be a better cap than three and I cannot recall the source for that which was sited. A tuple in C# only grows up to seven items come to think of it. Anyways, I am not in love with these method size restrictions. I think objects are healthy, but not superobjects composed of many objects. Do not break with the Single Responsibility Principle. I once made an application wherein I put all of the interfaces for external dependencies in an external dependencies God object and handed it around to everything and it was a mistake. It reduced the readability of code (we read code more than we write code, remember) and it made it harder to make method signatures distinct in an overloading pattern.