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 observe physical properties of an object to be different and neither be incorrect. Over time, this concept has slowly been changing the way I program, to the point where now I tend to break up classes into 2 main categories, data objects and observing (function only) objects.

For the sake of this not becoming a elaborate and lengthy post for such a simple question, I'll try to explain what I mean through two examples.

First, take for instance this type of code, which I used to often write:

class Deck
{
    private Card[] cards;

    public void Shuffle()
    {
        // shuffle algorithm
    }

    // other deck related functions like draw, cut, etc...
}

I typically now write the same scenario as:

class Deck
{
    // by intention, i just mean some kind of immutable collection of cards
    private ReadonlyCollection<Card> _Cards;

    public Card[] Cards { get { return this._Cards; } }
}

interface IDeckHandler
{
    Deck Shuffle(Deck deck);
    // other deck related functions like draw, cut, etc..
}

class Dealer : IDeckHandler
{
    // IDeckHandler implementation
}

The Deck is no longer responsible for implementing the functions which can act on it. Or to make it fit the terminology, the deck is just a set of values and the way in which it is observed is the responsibility of the observer. Naturally, there can be many observers who perform the actions differently.

For the second example, I'll use something which people I have tried to explain this to have had an easier time with. Take the situation where we have colored letters on colored paper which spell out a word. We have an agent whose responsibility it is to read the word on the paper. Now assume the agent is some type of color blind. The image being emitted from the paper is the same, but the perception could be different. The observer does not have intimate knowledge of the object and cannot modify it, only respond with an interpretation of it.

As I have stated, this concept drives many of my development decisions. So back to the question, is this a published type of programming and if so, can you point me to some literature on it? There are some common and uncommon scenarios I have run into which are difficult to make decisions for, and certainly some things I just haven't thought of or run into yet which would hopefully have been examined in literature.

Answer 1

It seems to me like you're implementing functional programming in an OOP way. Regardless of the Physics explanation about "special relativity" , The entire idea of OOP is basically encapsulation - You want to objects to know themselves how everything should be done. Basically what you're saying here is "no , there is only data and functions that work on the data" . What if the deck changes? you get a new Dealer? how will you know which dealer should be created to deal the new deck?

If you thought about a "switch" statement , then you're hammering OOP concepts into a functional programming template.

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

This design pattern can work well, particularly if the operations do not mutate the original data objects. In .NET, for instance, LINQ and its associated extension methods can be seen as general operations for dealing with enumerations, so that the enumerations themselves do not need to know how they may be used. The methods do not, however, mutate the collections being enumerated, but merely provide a new way to interpret, filter and group the enumeration.

If the functionality is mutating the original objects, however, then I tend to prefer that functionality to be encapsulated as methods on the object. That way the object is responsible for maintaining its own invariants and you insulate more of the implementation details from the clients of the object. The more implementation detail you must leak in order to work with the object, the more opportunity there is for it to be used incorrectly and cause bugs.

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

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 7

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.