OO design: generic handling of sub classes that introduce new fields

Question

This is a design issue I keep running into, so I thought I would finally put it out there and see how people would approach it. The problem is as follows:

I identify a certain class that for the most part describes all instances of objects I will use, both behaviour and data-wise. That's great and works well for basic objects. Then a few other type of object crop up which need the same data and behaviour, but additionally would like to have an extra field here and there, or an extra data structure.

Let's call the class Something:

public class Something {
    private int id;
    private String fieldA;
    private String fieldB;
    private List<Data> list;

    // Then we have getters, setters, and some base methods
}

Sometimes we'll need to use SomethingElse and SomethingDifferent. They are 90% like Something in that the same data and behaviour describes them, however they each additionally have extra fields which need to be used by the rest of the program:

public class SomethingElse extends Something {
    private String dataSpecificToSomethingElse;
    // Then we have getters, setters, and some new-data specific methods
}

public class SomethingDifferentextends Something {
    private List<DifferentData> dataSpecificToSomethingDifferent;
    // Then we have getters, setters, and some new-data specific methods
}

I would like to come up with a decent way to handle the Something family of objects in a generic OO manner, as I would not like to couple the rest of my application on concrete implementation details (because we might need to add SomethingWacky later on). I don't want to deal with the subclasses directly as that breaks polymorphism, and will likely include a need to downcast/do a type switch - yuck.

The approaches I can think of to resolve this are as follows:

1. Create an abstract base class that defines all the methods for the Something family. Children then only implement the behaviour they are concerned with providing, leaving a NOP/blank override for methods that are not of concern. This enables everything to be treated the same, but introduces interface bloat.
2. Move responsibility to the base class via generic worker methods, following Tell, Don't Ask. For example this might be things like display(), doWork(), persist(), getStateFromDisplay(), etc. Each subclass would then take into consideration its data when overriding these base methods. I read an article by Allen Holub recently that suggested something like this might be a good practice. This seems to be moving way too much responsibility for external concerns to the class.
3. Create some sort of a data class that groups all of the extra data/behaviour from subclasses, and refer to that in Something. This doesn't feel very OO-like.

I've used approach 1 during a previous project - but in that instance even though each subclass only implemented/overrode the methods it cared about, the operations were actually generic enough so it was plausible that a class could coherently implement all or only some.

Each approach feels dirty in a way and I don't really like any. What are my alternatives? Perhaps I am totally misusing inheritance or approaching this the wrong way entirely. I'm open to any suggestions and would like to leverage OO techniques to come up with cleaner, decoupled designs. I'd really like to know how people have resolved issues like this, and any resources you could refer me to would be much appreciated.

Thanks

Answer 1

When the need to add SomethingElse, SomethingDifferent, etc. crops up, I'd ask: Does SomethingElse really need to be able to individually access all data and behavior elements of Something? Or is its use of Something limited to a few methods?

If it's the latter, it's usually a good idea to encapsulate the specific behavior of Something that is frequently used by other classes, and then use composition rather than inheritance.