Clay

As with other development tooling or style, there is often times more than one right answer. As such, I can think of quite a few situations where composing objects and behavior at runtime might be a good fit. For instance, if data that I'm using is large and constantly changing its structure, order, or otherwise unreliable, writing concrete implementations might be difficult or time consuming. A prefered approach may be just to provide an interface that describes only the data I need without requiring the ceremony and additional development time introducing formal DTO objects for only the unreliable portions. This saves time by allowing data i need to be parsed using redundant boilerplate parse code encapsulated within a single implementation provided by Clay. The benefit is realized once you consider that i was free from worrying about typos introduced when using a hand created map and that Clay has cross-checked the materialized data against a strongly typed interface which I then use in the rest of the code.

That's choice, and choice is good.

Yes, this is what we want.

And is this what we want? Less compile time typing/checking, more loosely typed stuff. Types are like unit tests. They take time, but they reduce errors.