Is it possible to have an empty subclass that extends an abstract class?

Question

Consider the following:

public abstract class Item { String name; String description; //concrete getters and setters follow } public class InventoryItem extends Item { //empty subclass of Item } public class CartItem extends Item { int quantity; int tax; //getters and setters for quantity and tax follow } 

InventoryItem is an item available for sale, while CartItem is an item that is added to the cart, so it has additional properties such as quantity and tax. Is it possible to have an empty subclass of the abstract class Item in this scenario?

Option 2: we may have an empty Item interface. InventoryItem implements Item and defines name and description properties and has getters and seters. CartItem will extend to InventoryItem and will define quantity and tax as properties and have getters and setters.

Option 3: It would be better to have an element interface. InventoryItem will execute Item. Then we could have a CartItem class that has an “item” and “two properties”, namely “tax and quantity”

Answer 1

I think there is nothing wrong with this design: it explicitly designates Item as the base, and InventoryItem / CartItem as executable classes. I would rename Item to AbstractItem (Java class libraries do this) to emphasize the fact that the intended use for the class should be used as a base for other classes.

There are special problems related to C ++, such as assigning with a base pointer , which makes it very desirable to make all non-leaf classes abstract. Although the rule does not literally translate into Java, I think it’s still a good idea to make abstract abstract classes, even if the class is self-contained. This will help you make a clear distinction between classes intended for direct instance and classes intended for extension, which is useful for serving people who are not familiar with your code base.

Taking this rule one step further, it is customary in Java to distribute all leaf final classes. This is a good defense rule, especially when your classes are immutable.

EDIT: Regarding the elements of the model in the cart, inheritance is not the best option. In fact, I think this is wrong. I would make my CartItem my own Item , and not expand it, because the item did not become another kind of entity, being placed in the basket. Here is how I think it should be modeled:

 public class Item { String name; String description; ... } public class CartItem { Item item; int quantity; int tax; ... } 

Answer 2

Let me offer a slightly longer sentence or opinion that may provide some recommendations.

When designing - a hierarchy, I try to make distinctions only in behavior through polymorphism. In general, I try to avoid differences between objects only by data. Over the years, I even stopped creating inheritance hierarchies for structural “data objects” based on which variables they store.

Where I spend most of my time defining a common interface for an abstraction class, represents in terms of methods, and then the presence of subclasses that all lend themselves to the same interface, but with different behavior. (The principle of replacing Liskov)

In this case, I would consider a common interface / abstract class Item with a hierarchy of Item implementations that differ in how they add up, calculate their taxes, etc. I can have a .isInCatalog () method that tells me where the element is or its nature, if I have to handle it differently, but I will still try to encapsulate most of the element type logic in the implementation of my polymorphic methods.

Although these types of computations are usually performed in practice in batch / aggregation operations in a database and not in a single object, I would have at the abstract level .getTax () ,. getQuantity (), and then would have subclasses with different behavior. (Consider refactoring NullObject to not make any mistakes to avoid handling zeros)

The few principles that help this design are described here in this solid blog:

http://codebork.com/2009/02/18/solid-principles-ood.html