Question

Let’s say I have one class Foo that has a bunch of logic in it and another class Bar which is essentially the same. However, as Foo and Bar are different (but related) entities I need the difference to be apparent from my code (i.e. I can tell whether an instance is a Foo or a Bar)

As I was whacking this together without much thought I ended up with the following:

public class Foo {   /* constructors, fields, method, logic and what-not */ }  public class Bar extends Foo {   /* nothing here but constructors */  } 

Is this OK? Is it better to make Bar a composite class? e.g:

public class Bar {   private Foo foo;    /* constructors and a bunch of wrapper methods that call      into foo */ } 

Or even, while we’re at it, something much more low-tech:

public class Foo {   /* constructors, fields, method, logic and what-not */    private boolean isABar; // Could be an enum } 

What do you think? How do you deal with these ‘marker classes’?

---

As an example of how my code may wish to treat Foo and Bar differently, my code would need to be able to do stuff like List<Foo> and List<Bar>. A Foo couldn’t go in a List<Bar> and vice versa.

Answer 1

In my opinion, it’s best if Foo and Bar subclass off a common ancestor class (maybe AbstractFoo), which has all the functionality. What difference in behaviour should exist between Foo and Bar? Code that difference as an abstract method in AbstractFoo, not by using a if statement in your code.

Example: Rather than this:

if (foo instanceof Bar) {     // Do Bar-specific things } 

Do this instead:

class Bar extends AbstractFoo {     public void specialOp() {         // Do Bar-specific things     } }  // ... foo.specialOp(); 

The benefit of this approach is that if you need a third class, that’s much like Foo but has just a little bit of difference, you don’t have to go through all your code and add edit all the if statements. 🙂