When to subclass and when to use attributes in an object model [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

I'm looking for some guidance for an object model I'm working on for an evaluation tool. There are currently two types of evaluations

• Peer
• Team

The only difference between these two evaluations is the way that a form is presented to a user in the UI. The peer evaluation will show peers in your team that you should evaluate based on some criteria, and the team evaluation will show all the teams involved to be evaluated based on some criteria. Other than that these two evaluations are exactly the same.

When building an object model should I make an abstract Evaluation object and then subclass the Peer evaluation and the Team evaluation? Or should I create an Evaluation object and have two attributes to represent the two different types of evaluations?

In the future there could possibly be more types of evaluations added.

Answer 1

In general, if the type is just a piece of information, you make it a field. If it's used to change the behavior of the methods like

public void foo() {
    if (type == PEER) {
        doSomething();
    }
    else {
        doSomethingElse();
    }
}

then it's an indication that you should subclass, and use polymorphism to get the appropriate behavior depending on the type. Another solution is to use delegation rather than inheritance, and to associate behavior to the type:

public enum EvaluationType {
    PEER {
        @Override
        public void foo() {
            ...
        }
    },
    TEAM {
        @Override
        public void foo() {
            ...
        }
    };

    public abstract void foo();
}

public class Evaluation {
    private EvaluationType type;

    public void foo() {
        return this.type.foo();
    }
}

Answer 2

Giving this a bit of thought, it seems to me like storing this information in the Evaluation object itself is the wrong way to go. Consider a real world example - a pumpkin seed. Now, I could either plant the seed, or I could roast and eat the seed. In fact, for a given seed, I could go one way, or the other, but not both: some seeds have been set aside for eating, and some for planting, but the division has little to do with the seed, per se.

As such, I'd suggest encoding the distinction somewhere else... perhaps you have an EvaluationModel that maintains separate collections (team vs. peer) and forwards those to the UI as appropriate. Why should an Evaluation care how others use it? What you need is an entity whose job it is to care, and let that guy draw what distinctions he will.

Answer 3

Take out the common properties and methods to an interface Say ICommon, and then have team and peer their own interface that implement ICommon...

interface ICommon{
}

interface ITeam:ICommon{
}

interface IPeer:ICommon{
}

and then implement each interface ( IPeer and ITeam) and your EvaluationManager ( if you have one) would know when to instantiate each object