Zero behavior objects in OOP - my design dilemma

Question

The basic idea behind OOP is that data and behavior (upon that data) are inseparable and they are coupled by the idea of an object of a class. Object have data and methods that work with that (and other data). Obviously by the principles of OOP, objects that are just data (like C structs) are considered an anti-pattern.

So far so good.

The problem is I have noticed that my code seems to be going more and more in the direction of this anti-pattern lately. Seems to me that the more I try to achieve information hiding between classes and loosely coupled designs, the more my classes get to be a mix of pure data no behavior classes and all behavior no data classes.

I generally design classes in a way which minimizes their awareness of other classes' existence and minimizes their knowledge of other classes' interfaces. I especially enforce this in a top-down fashion, lower level classes don't know about higher level classes. E.g.:

Suppose you have a general card game API. You have a class Card. Now this Card class needs to determine visibility to players.

One way is to have boolean isVisible(Player p) on Card class.

Another is to have boolean isVisible(Card c) on Player class.

I dislike the first approach in particular as it grants knowledge about higher level Player class to a lower level Card class.

Instead I opted for the third option where we have a Viewport class which, given a Player and a list of cards determines which cards are visible.

However this approach robs both Card and Player classes of a possible member function. Once you do this for other stuff than visibility of cards, you are left with Card and Player classes which contain purely data as all functionality is implemented in other classes, which are mostly classes with no data, just methods, like the Viewport above.

This is clearly against the principal idea of OOP.

Which is the correct way? How should I go about the task of minimizing class interdependencies and minimizing assumed knowledge and coupling, but without winding up with weird design where all the low level classes contain data only and high level classes contain all the methods? Does anyone have any third solution or perspective on class design which avoids the whole problem?

P.S. Here's another example:

Suppose you have class DocumentId which is immutable, only has a single BigDecimal id member and a getter for this member. Now you need to have a method somewhere, which given a DocumentId returns Document for this id from a database.

Do you:

• Add Document getDocument(SqlSession) method to DocumentId class, suddenly introducing knowledge about your persistence ("we're using a database and this query is used to retrieve document by id"), the API used to access DB and the like. Also this class now requires persistence JAR file just to compile.
• Add a some other class with method Document getDocument(DocumentId id), leaving DocumentId class as dead, no behavior, struct-like class.

Answer 1

What you describe is known as an anemic domain model. As with many OOP design principles (like Law of Demeter etc.), it's not worth bending over backwards just to satisfy a rule.

Nothing wrong about having bags of values, as long as they don't clutter the entire landscape and don't rely on other objects to do the housekeeping they could be doing for themselves.

It would certainly be a code smell if you had a separate class just for modifying properties of Card - if it could be reasonably expected to take care of them on its own.

But is it really a job of a Card to know which Player it is visible to?

And why implement Card.isVisibleTo(Player p), but not Player.isVisibleTo(Card c)? Or vice versa?

Yes, you can try to come up with some sort of a rule for that as you did - like Player being more high level than a Card (?) - but it's not that straightforward to guess and I'll have to look in more than one place to find the method.

Over time it can lead to a rotten design compromise of implementing isVisibleTo on both Card and Player class, which I believe is a no-no. Why so? Because I already imagine the shameful day when player1.isVisibleTo(card1) will return a different value than card1.isVisibleTo(player1). I think - it's subjective - this should be made impossible by design.

Mutual visibility of cards and players should better be governed by some sort of a context object - be it Viewport, Deal or Game.

It's not equal to having global functions. After all, there may be many concurrent games. Note that the same card can be used simultaneously on many tables. Shall we create many Card instances for each ace of spade?

I might still implement isVisibleTo on Card, but pass a context object to it and make Card delegate the query. Program to interface to avoid high coupling.

As for your second example - if the document ID consists only of a BigDecimal, why create a wrapper class for it at all?

I'd say all you need is a DocumentRepository.getDocument(BigDecimal documentID);

By the way, while absent from Java, there are structs in C#.

See

• http://msdn.microsoft.com/en-us/library/ah19swz4.aspx

• http://msdn.microsoft.com/en-us/library/0taef578.aspx

for reference. It's a highly object-oriented language, but noone makes a big deal out of it.

Answer 2

The basic idea behind OOP is that data and behavior (upon that data) are inseparable and they are coupled by the idea of an object of a class.

You're making the common error of assuming that classes are a fundamental concept in OOP. Classes are just one particularly popular way of achieving encapsulation. But we can allow that to slide.

Suppose you have a general card game API. You have a class Card. Now this Card class needs to determine visibility to players.

GOOD HEAVENS NO. When you are playing Bridge do you ask the seven of hearts when it is time to change the dummy's hand from a secret known only to the dummy to being known by all? Of course not. That's not a concern of the card at all.

One way is to have boolean isVisible(Player p) on Card class. Another is to have boolean isVisible(Card c) on Player class.

Both are horrid; don't do either of those. Neither the player nor the card are responsible for implementing the rules of Bridge!

Instead I opted for the third option where we have a Viewport class which, given a Player and a list of cards determines which cards are visible.

I've never played cards with a "viewport" before, so I have no idea what this class is supposed to encapsulate. I have played cards with a couple decks of cards, some players, a table, and a copy of Hoyle. Which one of those things does Viewport represent?

However this approach robs both Card and Player classes of a possible member function.

Good!

Once you do this for other stuff than visibility of cards, you are left with Card and Player classes which contain purely data as all functionality is implemented in other classes, which are mostly classes with no data, just methods, like the Viewport above. This is clearly against the principal idea of OOP.

No; the basic idea of OOP is that objects encapsulate their concerns. In your system a card isn't concerned about much. Neither is a player. This is because you are accurately modeling the world. In the real world, the properties are cards that are relevant to a game are exceedingly simple. We could replace the pictures on the cards with the numbers from 1 to 52 without much changing the play of the game. We could replace the four people with mannequins labeled North, South, East and West without much changing the play of the game. Players and cards are the simplest things in the world of card games. The rules are what is complicated, so the class that represents the rules is where the complication should be.

Now, if one of your players is an AI, then its internal state could be extremely complicated. But that AI doesn't determine whether it can see a card. The rules determine that.

Here's how I'd design your system.

First off, cards are surprisingly complicated if there are games with more than one deck. You have to consider the question: can players distinguish between two cards of the same rank? If player one plays one of the seven of hearts, and then some stuff happens, and then player two plays one of the seven of hearts, can player three determine that it was the same seven of hearts? Consider this carefully. But aside from that concern, cards should be very simple; they're just data.

Next, what is the nature of a player? A player consumes a sequence of visible actions and produces an action.

The rules object is what coordinates all of this. The rules produce a sequence of visible actions and inform the players:

• Player one, the ten of hearts has been handed to you by player three.
• Player two, a card has been handed to player one by player three.

And then asks the player for an action.

• Player one, what do you want to do?
• Player one says: treble the fromp.
• Player one, that is an illegal action because a trebled fromp produces an indefensible gambit.
• Player one, what do you want to do?
• Player one says: discard the queen of spades.
• Player two, player one has discarded the queen of spades.

And so on.

Separate your mechanisms from your policies. The policies of the game should be encapsulated in a policy object, not in the cards. The cards are just a mechanism.

Answer 3

You are correct that the coupling of data and behaviour is the central idea of OOP, but there's more to it. For example, encapsulation: OOP/modular programming allow us to separate a public interface from implementation details. In OOP this means that the data should never be publicly accessible, and should only be used via accessors. By this definition, an object without any methods is indeed useless.

A class that offers no methods beyond accessors is essentially an overcomplicated struct. But this isn't bad, because OOP gives you the flexibility to change internal details, which a struct does not. For example, instead of storing a value in a member field, it could be recomputed each time. Or a backing algorithm is changed, and with it the state that has to be kept track of.

While OOP has some clear advantages (esp. over plain procedural programming), it is naive to strive for “pure” OOP. Some problems do not map well to an object oriented approach, and are solved more easily by other paradigms. When encountering such a problem, do not insist on an inferior approach.

• Consider calculating the Fibonacci sequence in an object oriented manner. I can't think of a sane way to do that; simple structured programming offers the best solution to this problem.

• Your isVisible relation belongs to both classes, or to neither, or actually: to the context. Behaviourless records are typical of a functional or procedural programming approach, which seems to be the best fit to your problem. There is nothing wrong with

  static boolean isVisible(Card c, Player p);
  

  and there is nothing wrong with Card having no methods beyond rank and suit accessors.

Answer 4

The basic idea behind OOP is that data and behavior (upon that data) are inseparable and they are coupled by the idea of an object of a class. Object have data and methods that work with that (and other data). Obviously by the principles of OOP, objects that are just data (like C structs) are considered an anti-pattern. (...) This is clearly against the principal idea of OOP.

This is a tough question because it's based on quite a few faulty premises:

1. The idea that OOP is the only valid way to write code.
2. The idea that OOP is a well-defined concept. It's become such a buzzword that it's hard to find two people that can agree on what OOP is about.
3. The idea that OOP is about bundling data and behavior.
4. The idea that everything is/should be an abstraction.

I won't touch upon #1-3 much, because each could spawn their own answer, and it invites a lot of opinion-based discussion. But I find the idea of "OOP is about coupling data and behavior" to be especially troubling. Not only does it lead to #4, it also leads to the idea that everything should be a method.

There's a difference between the operations that define a type, and the ways you can use that type. Being able to retrieve the ith element is essential to the concept of an array, but sorting is just one of the many things I can choose to do with one. Sorting doesn't need to be a method any more than "create a new array containing only the even elements" needs to be.

OOP is about using objects. Objects are just one way of achieving abstraction. Abstraction is a means to avoid unnecessary coupling in your code, not an end all unto itself. If your notion of a card is defined solely by the value of its suite and rank, it's fine to implement it as simple tuple or record. There's no non-essential details that any other part of the code could form a dependency on. Sometimes you just don't have anything to hide.

You wouldn't make isVisible a method of the Card type because being visible is likely not essential to your notion of a card (unless you have very special cards that can turn translucent or opaque...). Should it be a method of the Player type? Well, that's probably not a defining quality of players either. Should it be a part of some Viewport type? Once again that depends on what you define a viewport to be and whether the notion of checking the visibility of cards is integral to defining a viewport.

It's very much possible isVisible should just be a free function.

Answer 5

Obviously by the principles of OOP, objects that are just data (like C structs) are considered an anti-pattern.

No, they aren't. Plain-Old-Data objects are a perfectly valid pattern, and I would expect them in any program that deals with data that needs to be persisted or communicated between distinct areas of your program.

While your data-layer might spool up a full Player class when it reads in from the Players table, it could instead just be a general data library that returns a POD with the fields from the table, which it passes to another area of you program which converts a player POD to your concrete Player class.

Use of data objects, either typed or untyped, may not make sense in your program, but that doesn't make them an anti-pattern. If they make sense, use them, and if they don't, don't.

Answer 6

Personally I think Domain Driven Design helps to bring clarity to this issue. The question I ask is, how do I describe the card game to human beings? In other words, what am I modeling? If the thing I'm modeling genuinely includes the word "viewport" and a concept that matches its behavior, then I would create the viewport object and have it do what it logically should.

However if I don't have the concept of the viewport on my game, and it's something I think I need because otherwise the code "feels wrong". I think twice about adding it my domain model.

The word model means that you are building a representation of something. I caution against putting in a class that represents something abstract beyond the thing that you are representing.

I will edit to add that it's possible that you may need the concept of a Viewport in another part of your code, if you need to interface with a display. But in DDD terms this would be an infrastructure concern and would exist outside of the domain model.

Answer 7

I am not sure the question at hand is being answered at the right level. I had urge the wise in the forum to actively think on the core of the question here.

U Mad is bringing up a situation where he believes that programming as per his understanding of OOP would generally result in a lot of leaf nodes being data holders while his upper level API is comprises of most of the behavior.

I think the topic went slightly tangential into whether isVisible would be defined on Card vs Player; it was a mere example illustrated, albeit naive.

I had push the experienced here to look at the problem at hand though. I think there is a good question that U Mad has pushed for. I understand that you would push the rules and the concerned logic to an object of its own; but as I understand the question is

1. Is it OK to have simple data holder constructs (classes / structs ; I don't care about what they are modeled as for this question) which do not really offer much functionality ?
2. If yes, What is the best or preferred way to model them?
3. If no, how do we incorporate this data counter parts into higher API classes (including behavior)

My view:

I think you are asking a question of granularity that is hard to get right in object oriented programming. In my little experience, I would not include an entity in my model that does not include any behavior by itself. If I have to, I had probably use a construct a struct that is designed to hold such abstraction unlike a class that has the idea of encapsulating data and behavior.

Answer 8

I don't usually do self-promotion, but the fact is I wrote a lot about OOP design issues on my blog. To sum up several pages: you shouldn't start design with classes. Starting with interfaces or APIs and shape code from there have higher chances to provide meaningful abstractions, fit specifications and avoid bloating concrete classes with non-reusable code.

How this apply to Card-Player problem: Creating a ViewPort abstraction makes sense if you think of Card and Player as being two independent libraries (which would imply Player is sometimes used without Card). However, I'm inclined to think a Player holds Cards and should provide a Collection<Card> getVisibleCards () accessor to them. Both these solutions (ViewPort and mine) are better than providing isVisible as a method of Card or Player, in terms of creating understandable code relationships.

An outside-the-class solution is much, much better for the DocumentId. There is little motivation to make (basically, an integer) depend on a complex database library.

Answer 9

One common source of confusion in OOP stems from the fact that many objects encapsulate two aspects of state: the things they know about, and the things that know about them. Discussions of objects' state frequently ignore the latter aspect, since in frameworks where object references are promiscuous there is no general way to determine what things might know about any object whose reference has ever been exposed to the outside world.

I would suggest that it would probably be helpful to have a CardEntity object which encapsulates those aspects of the card in separate components. One component would relate to the markings on the card (E.g. "Diamond King" or "Lava Blast; players have AC-3 chance to dodge, or else take 2D6 damage"). One might relate to a unique aspect of state such as position (e.g. it's in the deck, or in Joe's hand, or on the table in front of Larry). A third might relate to can see it (perhaps nobody, perhaps one player, or perhaps many players). To ensure that everything is kept in sync, places where a card might be would not be encapsulated as simple fields, but rather CardSpace objects; to move a card to a space, one would give it a reference to the proper CardSpace object; it would then remove itself from the old space and put itself into the new space).

Explicitly encapsulating "who knows about X" separately from "what X knows" should help avoid a lot of confusion. Care is sometimes needed to avoid memory leaks, especially with many-many associations (e.g. if new cards can come into existence and old cards disappear, one must ensure that cards which should be abandoned aren't left perpetually attached to any long-lived objects) but if the existence of references to an object will form a relevant part of its state, it's entirely proper for the object itself to explicitly encapsulate such information (even if it delegates to some other class the work of actually managing it).

Answer 10

However this approach robs both Card and Player classes of a possible member function.

And how is that bad/ill-advised?

To use a similar analogy to your cards example, consider a Car, a Driver and you need to determine if the Driver can drive the Car.

OK, so you decided that you don't want your Car to know if the Driver has the right car key or not, and for some unknown reason you also decided you don't want your Driver to know about the Car class (you didn't fully flesh this out in your original question as well). Hence, you have an intermediary class, something along the lines of an Utils class, which contains the method with business rules in order to return a boolean value for the question above.

I think this is fine. The intermediary class may only need to check for car keys now, but can be refactored to consider if the driver has a valid driving license, under the influence of alcohol, or in a dystopian future, check for DNA biometrics. By encapsulation, there is really no big problems having these three classes co-existing together.