Inheritance vs additional property with null value

Question

For classes with optional fields, is it better to use inheritance or a nullable property? Consider this example:

class Book {
    private String name;
}
class BookWithColor extends Book {
    private String color;
}

or

class Book {
    private String name;
    private String color; 
    //when this is null then it is "Book" otherwise "BookWithColor"
}

or

class Book {
    private String name;
    private Optional<String> color;
    //when isPresent() is false it is "Book" otherwise "BookWithColor"
}

The code depending on these 3 options would be:

if (book instanceof BookWithColor) { ((BookWithColor)book).getColor(); }

or

if (book.getColor() != null) { book.getColor(); }

or

if (book.getColor().isPresent()) { book.getColor(); }

The first approach looks more natural to me, but maybe it is less readable because of the necessity to do casting. Is there some other way to achieve this behavior?

Answer 1

It depends on the circumstances. The specific example is unrealistic since you wouldn't have a subclass called BookWithColor in a real program.

But in general, a property which only makes sense for certain subclasses should only exist in those subclasses.

For example if Book has PhysicalBook and DigialBook as descendents, then PhysicalBook might have a weight property, and DigitalBook a sizeInKb property. But DigitalBook will not have weight and vice versa. Book will have neither property, since a class should only have properties shared by all descendents.

A better example is looking at classes from real software. The JSlider component has the field majorTickSpacing. Since only a slider has "ticks", this field only makes sense for JSlider and its descendants. It would be very confusing if other sibling components like JButton had a majorTickSpacing field.

Answer 2

An important point that doesn't seem to have been mentioned: In most languages, instances of a class cannot change which class they are instances of. So if you had a book without a colour, and you wanted to add a colour, you'd need to create a new object if you are using different classes. And then you'd probably need to replace all references to the old object with references to the new object.

If "books without colour" and "books with colour" are instances of the same class, then adding the colour or removing the colour will be much less of a problem. (If your user interface shows a list of "books with colour" and "books without colour" then that user interface would have to change obviously, but I'd expect that's something you need to handle anyway, similar to a "list of red books" and "list of green books").

Answer 3

Think of a JavaBean (like your Book) as a record in a database. Optional columns are null when they have no value, but it is perfectly legal. Therefore, your second option:

class Book {
    private String name;
    private String color; // null when not applicable
}

Is the most reasonable.¹

Be careful though with how you use the Optional class. For example, it isn't Serializable, which is usually a characteristic of a JavaBean. Here are some tips from Stephen Colebourne:

1. Do not declare any instance variable of type Optional.
2. Use null to indicate optional data within the private scope of a class.
3. Use Optional for getters that access the optional field.
4. Do not use Optional in setters or constructors.
5. Use Optional as a return type for any other business logic methods that have an optional result.

Therefore, within your class you should use null to represent that the field is not present, but when the color leaves the Book (as a return type) it should be wrapped with an Optional.

return Optional.ofNullable(color); // inside the class

book.getColor().orElse("No color"); // outside the class

This provides clear design and more readable code.

---

¹ If you intend for a BookWithColor to encapsulate a whole "class" of books which have specialized capabilities over other books, then it would make sense to use inheritance.

Answer 4

You should either use an interface (not inheritance) or some kind of property mechanic (maybe even something that works like the resource description framework).

So either

interface Colored {
  Color getColor();
}
class ColoredBook extends Book implements Colored {
  ...
}

or

class PropertiesHolder {
  <T> extends Property<?>> Optional<T> getProperty( Class<T> propertyClass ) { ... }
  <V, T extends Property<V>> Optional<V> getPropertyValue( Class<T> propertyClass ) { ... }
}
interface Property<T> {
  String getName();
  T getValue();
}
class ColorProperty implements Property<Color> {
  public Color getValue() { ... }
  public String getName() { return "color"; }
}
class Book extends PropertiesHolder {
}

Clarification (edit):

Simply adding optional fields in the entity class

Especially with the Optional-wrapper(edit: see 4castle's answer) I think this (adding fields in the original entity) is a viable way to add new properties in a small scale. The biggest problem with this approach is that it might work against low coupling.

Imagine your book class is defined in a dedicated project for your domain model. Now you add another project that uses the domain model to do a special task. This task requires an additional property in the book class. Either you end up with inheritance (see below) or you have to change the common domain model to make the new task possible. In the latter case you may end up with a bunch of projects that all depend on their own properties added to the book class while the book class itself in a way depends on these projects, because you are not able to understand the book class without the additional projects.

Why is inheritance problematic when it comes to a way to provide additional properties?

When I see your example class "Book" I think about a domain object that often ends up having many optional fields and subtypes. Just imagine you want to add a property for books that include a CD. There are now four kinds of books: books, books with color, books with CD, books with color and CD. You cannot describe this situation with inheritance in Java.

With interfaces you circumvent this issue. You can easily compose the properties of a specific book class with interfaces. Delegation and composition will make it easy to get exactly the class you want. With inheritance you usually end up with some optional properties in the class that are only there because a sibling class needs them.

Further reading why inheritance is often a problematic idea:

Why is inheritance generally viewed as a bad thing by OOP proponents

JavaWorld: Why extends is evil

The problem with implementing a set of interfaces to compose a set of properties

When you use interfaces for extension everything is fine as long as you have just a small set of them. Especially when your object model is used and extended by other developers e.g. in your company the amount of interfaces will grow. And eventually you end up creating a new official "property-interface" that adds a method your colleagues already used in their project for customer X for a completely unrelated use case - Ugh.

edit: Another important aspect is mentioned by gnasher729. You often want to dynamically add optional properties to an existing object. With inheritance or interfaces you would have to recreate the whole object with another class which is far from optional.

When you expect extensions to your object model to such an extent you will be better off by explicitly modelling the possibility of dynamic extension. I propose something like above where each "extension" (in this case property) has its own class. The class works as namespace and identifier for the extension. When you set the package naming conventions accordingly this way allows an infinite amount of extensions without polluting the namespace for methods in the original entity class.

In game development you often encounter situations where you want to compose behavior and data in many variations. This is why the architecture pattern entity-component-system got pretty popular in game development circles. This is also an interesting approach you might want to look at, when you expect many extensions to your object model.

Answer 5

If Book class is derivable without color property like below

class E_Book extends Book{
   private String type;
}

then inheritance is reasonable.