Is it bad practice to have an empty class as a base class, with the expectation that the class may have members in the future? [closed]

Question

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

As simple as I can put it, it is called Speculative Generality.

Reasons for the Problem: Sometimes code is created "just in case" to support anticipated future features that never get implemented. As a result, code becomes hard to understand and support.

---

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

_{Programmers are notoriously bad at guessing what functionality might be needed someday.}

_{1. Requirements aren't known, so programmer must guess: Wrong guesses will mean the code must be thrown away.}

_{2. Even a close guess will be wrong about the details: These intricacies will undermine the programmer's assumptions - the code must be (or should be) thrown away.}

_{3. Other/future programmers may assume the speculative code works better or is more necessary than it is: They build code on the foundation of speculative code, adding to the cost when the speculative code must be removed or changed.}

_{4. The speculative generality adds complexity and requires more testing and maintenance: This adds to the cost and slows down the entire project.}

---

^{Credits: Code Complete - 2 | Pluralsight course on refactoring.}

Answer 2

Imho It is an extra abstraction layer with no added value. It adds unnecessary complexity, so in my opinion it's bad practice and an example of YAGNI.