Are interfaces made useless by the template pattern?

Question

Refer to the highest upvoted answer here for why you should make an IPizza interface with a IPizza.Prepare() method.

This is highly upvoted, But I think the answer is flawed. Sure a pizza can be prepared, but so can literally anything. Interfaces are only a guarantee of behaviors, not a guarantee of type, proven here:

    public interface IPizza
    {
        void Prepare();
    }
    public class Sandwich : IPizza
    {
        public void Prepare() { }
    }

If you expect to anywhere use a Collection<IPizza>, you have introduced a vulerability, maybe not security-wise but logic-wise. Because simply naming something IPizza is a guarantee of nothing (regarding type).

The above developer now must reintroduce type checking if (IPizza is Pizza) which per the highest upvoted comment, was a reason to use interfaces.

You might be tempted to add a return type to the Prepare() method, i.e. IPizzaTopping Prepare() but again, until you factor out the interface you can make anything be an IPizzaTopping. Once you factor out one interface, you might as well factor them all out in favor of hard types.

Here is the pizza example using the template pattern, all hard types:

    public class Pizza
    {
        private void Add(PizzaTopping topping) { }

        protected virtual PizzaTopping? Subclass_PrepareTopping(){ return null; } // Template pattern

        public void Prepare()
        {
            ThrowDough();  // private method
            SpreadSauce(); // private method
            SpreadCheese(); // private method

            if(Subclass_PrepareTopping() is PizzaTopping p){ Add(p); } // This might weaken my point by needing a type check, but it is really only a null check which is more a weakness of collections than a weakness of this example.

            Bake(); //private method
        }
    }

    public class PepperoniPizza : Pizza
    {
        protected sealed override PizzaTopping Subclass_PrepareTopping()
        {
            return new PepperoniTopping();
        }
    }

Now any public user of a Pizza can call the Pizza.Prepare() method and be guaranteed to get exactly the correct preparation.

If you say "Well I'll just inherit from PizzaTopping and return a gravy, and aha! I invalidated this whole discussion!"

...well the point of OOP is to create abstractions to the granular level. It's your job to make sure a PizzaTopping contains properties like Collection<Cheese>,Collection<SlicedMeat>, where, when the user desires to create a new PizzaTopping, they must compose the topping from your predefined granular types, which at the granular level are all hard sealed types.

Is this logic wrong in any way? Is there a pizza preparation example that throws a wrench in the above?

Answer 1

I think there is a subtle distinction you're missing between guaranteeing consistency and guaranteeing truth.

When you write public class Sandwich : IPizza you are telling the compiler that a Sandwich is a type of IPizza. The compiler can then prove the consistency of code that passes a concrete Sandwich to something that is designed to work with any IPizza.

What the compiler can't do is verify the absolute truth of the English statement "a sandwich is a type of pizza". The step where real-world concepts are translated into types in the program is unavoidably performed by a human.

The purpose of defining the interface is that it leaves collaborating classes open to extension by providing them with new types of pizza. It defines a contract that those new types of pizza must follow. That contract doesn't tell you anything about whether the result will be pleasant to eat.

You might argue whether a chocolate pizza is a "real" pizza, but if your pizza-making machinery can handle one, then there is no problem declaring class ChocolatePizza : IPizza. However, trying to extend ChocolatePizza from a base Pizza class with default implementation is going to be a mess - it barely shares any of the same implementation, even though it can meet the same interface.

So, even though you didn't plan to support chocolate pizzas, your code was open to extension by someone else implementing that new class.

Answer 2

From responses to previous answers I'm unsure if this is an honest question or argued in bad faith. Assuming the former:

No language construct can "protect" against developer intent (or incompetence). If someone writes code that compiles but makes no sense ala

public class Sandwich : IPizza

well, that's on the developer. One can write all sorts of stuff that confuses and befuddles in any language (especially {your least favorite language here}). This doesn't make the language constructs used obsolete. It might say something about the author however....

Answer 3

Interfaces and generics are two very different, yet complementary things:

• An interface defines a behavioral contract. A class implementing IPizza must fulfill this contract, i. e. offer a Prepare method that meets the expectations. We don’t care if it’s a kind of pizza or not (for this we have classes). Btw, in real life projects, I never encountered any IPizza: naming of interfaces often describe a behavioral trait: IPrintable, IDeliverable, ISortable, IComparable. The problem with tutorial examples is that they are often obersimplified and thus misleading.
• Generics are using some kind of generalisation of a family of contracts or types to compose a more complex programming construct (e.g. class). Typically a collection of items that obey to dome sets of interfaces/types whose methods can be combined for making a more complex behavior. They do not substitute to interfaces. On contrary, they may use interfaces to define more complex containers.

By their essence, generics are compile-time type substitution, whereas interfaces offer a run-time polymorphism thanks to their defined contract.