Design Patterns – Adhering to a Protocol and Being a Subclass Simultaneously

design-patternsinterfacesobjective c

In objective C, I have a situation where I would like to have an abstract protocol (interface) with 5 methods and 4 properties, but at the same time, I'd like to have a common implementation of 3 of those 5 methods.

So my question is, is it ok to

1) have just an interface declaration with all the method and property declarations,

2) have a base class that adheres to that protocol (implements that interface) but also provides a common implementation of some of those classes, and only has empty stub method implementations for the rest of the methods, and then finally,

3) have a bunch of subclasses (from that base class), that will conform to that protocol – but – also inherit common method implementations -and – implement on their own those stub methods?

Best Answer

This is the pattern that is often used to address the lack of abstract classes in Objective C.

It is very common for the missing method stubs of the base implementation to raise an exception, to make sure that you catch incomplete implementations. See this answer on stack overflow for details of how it is commonly done.

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

When you need a part of the class to be implemented. The best example I've used is the template method pattern.

public abstract class SomethingDoer
{
    public void Do()
    {
        this.DoThis();
        this.DoThat();
    }

    protected abstract void DoThis();
    protected abstract void DoThat();
}

Thus, you can define the steps that will be taken when Do() is called, without knowing the specifics of how they will be implemented. Deriving classes must implement the abstract methods, but not the Do() method.

Extensions methods don't necessarily satisfy the "must be a part of the class" part of the equation. Additionally, iirc, extension methods cannot (appear to) be anything but public in scope.

edit

The question is more interesting than I had originally given credit for. Upon further examination, Jon Skeet answered a question like this on SO in favour of using interfaces + extension methods. Also, a potential downside is using reflection against an object hierarchy designed in this way.

Personally, I am having trouble seeing the benefit of altering a currently common practice, but also see few to no downsides in doing it.

It should be noted that it is possible to program this way in many languages via Utility classes. Extensions just provide the syntactic sugar to make the methods look like they belong to the class.

Objective C – Can Categories Serve the Same Purpose as Traits in Scala?

Importing (#import ...) an Objective-C category adds the methods defined in that category to all instances of the class on which the category was defined. Other than with traits which can be mixed into classes selectively a category extends the class on which it was defined once and for all.

Also you can not create a standalone category and mix that into several different classes. A category is an extension for a specific class, similar as if you would add the methods to the class itself.

Traits are like java interfaces but with implementation. Wether a trait can be mixed into a class depends not on the classes name but on the methods the class provides. If a class has the methods a trait needs, the trait can be mixed into that class.

Best Answer

Related Solutions

C# Design – When to Use Abstract Classes vs Interfaces with Extension Methods

Objective C – Can Categories Serve the Same Purpose as Traits in Scala?

Related Topic