Is there some literature on this type of programming?

Question

In college I took on a class on modern physics, in which we learned about special relativity. I was completely blown away by how different frames of reference could actually ob

Answer 1

Some aspects of this programming style are covered in Data-Oriented Programming (a development style that focuses on the layout and transformation of data).

My main problem with this style is that if there are implicit assumptions/constraints for a given type (e.g., say the card deck must never have 2 jokers in a row after a shuffle), you must duplicate those constraints/checks throughout all of the manager types since the data type you're operating on is totally dumb -- it can't look after itself, it's just a data bag. You can extract the duplicate logic into a separate method, but it's generally a bit harder to write good, clean code using this method.

Compare this to implementing a Deck.Shuffle method that takes an IDeckShuffle strategy. In this scenario, you can perform the shuffle and then add invariant checks as a post step to ensure that no matter what shuffle strategy was used, the deck will never enter an invalid state; the code that enforces integrity is in one place and is easy to verify and update.

Also, since the call to IDeckShuffler.Shuffle(...) comes from inside the Deck, the deck has access to all hidden fields and encapsulated state. As such, you can expose the minimum details to the deck shuffler implementation instead of defaulting to passing a Deck. Instead, you may pass IEnumerable or something even less specific, as opposed to passing the whole data bag by default.

Anyway, the form of development you're inquiring about is basically procedural programming. As such, it's harder to hide information and encapsulate things. In performance-critical systems this can be an acceptable trade-off (group all data by type, then iterate over it using the manager 'process' functions = good cache coherency).

In general development, I stay away from this style of programming as it severely hinders my ability to manage complexity. Ayende had a good post about this a while back. Although he's talking about a data storage object and the operations that act on it, the principle is exactly the same -- the separation of data and the functions that act on that data and the problems therein.