"It will create getters, setters and setting constructors for all private fields." - The way you describe this tool, it sounds like it is maintaining encapsulation. (At least in a loose, automated, somewhat anemic-model sense.) So what exactly is the problem?

@nocomprende: I'm really not following your reasoning at all here, or how it relates to the original question. If you're suggesting that, in any Turing-like system of input/calculation/output that the output can always be inferred from the input then, yes, that is true. There are 0 scenarios in the universe where that logic doesn't stand. That doesn't invalidate the need for calculation, though. The point of the computer is to perform that calculation. But this theoretical discussion seems really broad compared to the original question.

@nocomprende: I'm not sure how you leapt from "don't repeat information" to "don't use a computer at all"... I'm simply suggesting that one maintains a single source of truth in any given context for any given piece of information. The proposed alternative, manually keeping different sources of truth synchronized, is highly error-prone and overly-complex.

@nocomprende: It would still be a line or two of additional unnecessary code in that case. It's a very small example of the concept, of course. But it illustrates the point. You'd be storing the same value in multiple places. As the complexity of the system grows, the potential for bugs grows faster. Anybody working in that code needs to manually remember to keep all of the values synchronized, and humans aren't good at doing that. Exceptions can be made for very expensive calculations, but those are rare.

@AshutoshPandey: If the new added field is required, it is a change to the published API regardless of how it's implemented. If it's not required, then either approach would work the same to any external observer. There really isn't much of a difference at the published API level.

In the first approach, will the server-side code be peeking into the dictionaries and making assumptions/requirements about what they contain? If so, other than losing all compile-time type safety, what's the benefit over the second approach?

This reminds me of one of my favorite quotes: "The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time." - Tom Cargill