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

What you're doing is separating the data of the concept from the operations that act on that concept. What the system is from what the system does. This opens the door for many different scenarios, in which you change the behavior of the system by using different behavior classes. These behavior classes can also be reusable for different data classes. Many patterns address this problem, like Visitor, Command, Strategy, or Observer.

But there's something deeper at play here. Maybe we need another concept in our (mainstream) programming languages (or maybe just in our minds), that will allow us to separate, and reuse, these bahaviors.

The DCI architecture addresses these issues, and presents roles, or traits (pdf), as the fundamental unit of behavior and code reuse.

Answer 2

What you're talking about is one of the great "a HA!" moments that object oriented programmers run across. It's fun when it happens. I'd start with the gang of four "Design Patterns" book and branch out from there.

Answer 3

Interesting. Well, I think you are doing Model->Controller->View (MVC Pattern) but in this case you are only using the Controller and Model parts separately.

The gains here are clear if you have multiple scenarios in which the objects will be used, its a typical POJO+Managers way of doing things. In this case the objects themselves are dumb and without any functionality besides their own state.

The advantages are clear in the ways of separation of responsibility although the disadvantages are a bit more handling on the manager side of things.

If you think about it, if the objects don't do anything with themselves you are basically cutting out one level of indirection (the base level) and everything must be indirected to use. This means more code to handle unexpected situations, null objects and such. Perhaps more glue code than needed.

Flexible? Yes. Practical? Only you can answer.

Answer 4

In the Java world, we have nice containers, containing stateless session beans, which can be used precisely for separating behaviour from data, as formalised by the DCI Architecture. This is sometimes called service oriented programming.

OOP constrains designers by requiring behaviour to be placed in classes where the data lives, in order to increase coherence, rather than letting the designer put related data together, and related behaviour together, but not necessarily then also pushing the behaviour into those data classes.

In a good design, we sometimes have behaviour in classes, and sometimes we have behaviour in higher order classes.

Answer 5

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<Card> 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.

Answer 6

This is the typical way most applications are laid out. I think of classes as forming a dichotomy - data container objects and strategy objects. Data container objects are carriers of information whilst strategies are encapsulations of various kinds of algorithms that can be applied on the data containers.

Command pattern is very close to the strategy pattern. Strategies also tend to manifest themselves as controllers, facades and the like.

Data Container objects manifest as entities, model objects, value objects, data transfer objects etc.

Gang of four is a good start but you might want to look into other classic design patterns treatises for further elaboration. Depending on your programming language predilection, you might want to consider more specific pattern books as well. Amazon has a ton of lists on design patterns.

I had talked about class dichotomy in this article.