Is it really bad practice to have an empty class as a base class with the expectation that the class can have members in the future?

Question

A simple example:

public class Food { public virtual void Eat() { StuffInMouth(); } } public class Fruit : Food { // Nothing here yet, but likely could be in the future // Is this bad from a .NET/C# style guidelines perspective? } public class Apple : Fruit { public virtual void Eat() { Clean(); base.Eat(); } } public class Orange : Fruit { public virtual void Eat() { Peel(); base.Eat(); } } 

Answer 1

How can I say, it is called Speculative community .

Causes of the problem: Sometimes code is created “just in case” to support expected future functions that will never be implemented. As a result, the code becomes difficult to understand and maintain.

---

_{As Steve McConnell says in Code Complete - 2,}

_{Programmers are notoriously poorly guessing what kind of functionality they might need sometime.}

<sub> 1. The requirements are not known, so the programmer must guess: Incorrect guesses mean that the code must be thrown away.

<sub> 2. Even a rough guess will be wrong in the details: These subtleties undermine the programmer’s assumptions - the code should (or should) be thrown away.

<sub> 3. Other / future programmers may suggest that speculative code works better or is more necessary than it: They create code based on speculative code, adding to the cost when speculative code needs to be deleted or changed.

<sub> 4. Speculative commonality adds complexity and requires more testing and maintenance: This increases cost and slows down the entire project.

---

^{Credits: code completed - 2 | Pluralsight refactoring course .}

Answer 2

Imho This is an additional layer of abstraction without added value. This adds unnecessary complexity, so in my opinion this is bad practice and an example of YAGNI.

Answer 3

Yes, it is important to understand that although it can save time to do something like this (if used), it is usually better to code for the near future, or at least to understand when you code the future, it will never come.

In addition, the overhead of maintenance is too early.

Answer 4

No one said a class should have members. A class is a category of objects, so if they do not have useful properties (not in the sense of the language), it is completely normal for it to be empty. So, what is important is whether the class is a really significant category of objects that your code should work with or not.

In your case, if your code usually runs on food, Food has common ancestors. However, a more understandable concept can introduce the IFood interface, effectively IFood contract for the supply of products with actual inheritance hierarchies . For example, a meaningful hierarchy may begin with the Animal class, but not every animal is considered food (disclaimer: this is an example).