6

I always separate the user interface from other functionality in my programs - its the way I have been taught, and it has obvious advantages since you can change the interface but keep the same functionality.

However, I've come across some programmers who strictly separate data, algorithms and interface. So the data objects which hold the data in volatile memory have only fields/properties and their getters and setters. Any algorithms are kept in a separate class.

In my view the main disadvantage of this is that the algorithm classes usually need full access to the data in the data classes. You might want to have a more functional class which you create with lots of data but then objects from other classes can only get at that data in specialised ways.

  • 2
    What should we understand under 'algorithm'? Either way the same advantages of other separations apply: you can reuse the algorithm for a different object. – Jeroen Vannevel Mar 28 '14 at 12:21
4

It's called a Plain Old Data Structure (PODS). They are fairly common in places where data first enters a system from an external source, like a database. In effect their single responsibility is to abstract that external data into a form that's easier for higher layers to consume.

In other words, it allows programmers of higher layers to work with familiar native objects rather than having to sprinkle accesses to the external source throughout the code. That data is read into the system in one place, and only that one place must change if the interface to the external source changes.

Like any principle, it can be taken too far. If they're commonly using a PODS on internal-only data, it's probably misguided in OOP. Note however that passing around a PODS is a fairly common pattern in functional programming, for better or worse.

  • 3
    and its used as an architectural system in languages that do not have OO, such as C. There, you'd have a POD that is passed to a function that implements an algorithm (note: with no access restrictions). So it sounds like you might have a this style implemented in OO language constructs. – gbjbaanb Mar 28 '14 at 13:03
  • Thanks for the explanation of the PODS acronym. I can understand that it may be important to have access to the objects in one place, rather than different parts of the program having to get it from the database. But what I am confused about is why that data object can't have other responsibilities as well. – Paul Richards Mar 28 '14 at 14:21
  • Take for example an application where people can play cards, and save their part-completed games in a database. You have a deck class that represents the state of the stack of cards in the deck, which is loaded from the database. If it was a plan old data object then it would let you access any card, whereas some would say it would be better to have a more intelligent object which only lets you see the top card. – Paul Richards Mar 28 '14 at 14:23
1

When you encapsulate data, you're limiting yourself to only being able to perform a limited number of operations on it. But often there's an unbounded number of things you want to do with data.

Suppose we're writing a simple role-playing game. Let's write a Weapon class and examine what happens if we hide all its data.

public class Weapon {
    private int damage;
    private int accuracy;

    public Weapon(int damage, int accuracy) {
        this.damage = damage;
        this.accuracy = accuracy;
    }
}

Naturally, we want to be able to hit people with the weapon. So we need a function that calculates the damage we'll do to the enemy. But all the weapon's variables are private, so we'll have to turn that function into a method.

public int hitEnemy(Enemy theEnemy) {
    return theEnemy.getDefense() - this.damage;
}

We'll also need a way to determine if we succeeded in our attack. Again, this'll become a method.

public boolean tryToHit(Enemy theEnemy) {
    return random() > (theEnemy.getEvasion() - this.accuracy);
}

Later on we find that we want to compare two weapons to see which one has more damage. Another method.

public Order compareDamage(Weapon other) {
    if (this.damage > other.damage) {
        return Order.GREATER;
    } else if (this.damage < other.damage) {
        return Order.LESS;
    } else {
        return Order.EQUAL;
    }
}

A few days later we decide that a weapon's price should be determined based on its damage and accuracy...

public int getPrice() {
    return 10 * this.damage + 0.5 * this.accuracy;
}

The following week we want to give weapons ratings from C to A based on their stats...

public Rating getRating() {
    if (accuracy/10 + damage > 10) {
        return Rating.A;
    } else if (accuracy/10 + damage > 5) {
        return Rating.B;
    } else {
        return Rating.C;
 }

As you can see, every time we need to do anything new with the weapon, we need to throw that into the weapon's class to get at its variables. That's bad - it violates the Open/Closed Principle, which states that code should be open to extension and close to modification. If we had turned Weapon into a plain old data object - a simple record with nothing but public data - we'd be able to add functions to use weapons in new ways without having to modify the Weapon class.

When you design an abstraction X, you must distinguish between things X does and things I can do with X. Our weapons don't do anything, so there's no implementation details to hide. Hiding all their data behind private variables is about as useful as a list that doesn't let you access its elements. Our game will definitely need some encapsulation and abstraction, but it should be implemented at a higher layer, in the game logic proper.

  • 1
    Nice answer but I think you confused yourself between good OO practice of defining encapsulated types and wanting to expose everything in a class because you don't want to define its behaviour. I'm not sure you've really given an answer that answers the question :) – gbjbaanb Mar 28 '14 at 13:08
  • @gbjbaanb What is the behavior of a data object? – Doval Mar 28 '14 at 13:22
  • 1
    Depends what you mean, if you mean a POD then it has no behaviour - all implementation is implemented by (usually) free functions (eg in C programming), if you mean a data type, then it has behaviour according to the methods you give it. A weapon can be modelled as a data type, with methods that return weight, cost, damage, etc just like your example shows. – gbjbaanb Mar 28 '14 at 13:56
  • 1
    I thing getters are an anti-pattern, what you should be implementing is proper methods that return meaningful data based on your class. True, if all you are doing is implementing getters on a POD, then you might as well have a POD. If you were trying to explain this in your answer, putting methods like tryToHit, Compare and calculated getters like getCost are really bad examples, no wonder I was confused by your answer! – gbjbaanb Mar 28 '14 at 14:13
  • 1
    @gbjbaanb I was trying to illustrate what happens when you take something that should be a POD and then make its data private. Since the data is private, every time you need to write a new function it has to go straight into the class so it can get at the private variables. I'll edit the answer to make that clearer. – Doval Mar 28 '14 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.