Difference between class scope and object scope design patterns

design-patterns

Apparently design patterns have a ton of classifications. One I am struggling with is whether or not the pattern is a class scoped pattern or an object scoped pattern. Of course no documentation exists on the differences between the two, so I'm asking your opinion.

The GoF book defines it as:

"Class patterns deal with relationships between classes and their subclasses. These relationships are established through inheritance, so they are static-fixed at compile-time. Object patterns deal with object relationships, which can be changed at run-time and are more dynamic. Almost all patterns use inheritance to some extent. So the only patterns labelled "class patterns" are those that focus on class relationships. Note that most patterns are in the object scope."

Problem is, there are only class relationships as an object is nothing without its class. I've never heard of "object relationships" outside of this book.

Best Answer

This boils down to composition vs. inheritance.

Let's take a look at one pattern that you can do in both ways.

The adapter pattern is, as the name implies, an adapter between two classes that are otherwise incompatible.

Say you write a 3D engine and you need a Point class. You have your Point all ready and it kind of works, but then you find another class OtherPoint in some library that does everything your class should be doing in a nicer way, but its methods have different names. Your 3D engine expects your Point class.

What can you do to make both classes compatible in order to use OtherPoint class?

Point extends OtherPoint inheritance for the win. Point receives all the functionality it needs. The methods specific to your engine that Point declares simply call the corresponding ones from OtherPoint. This is the class pattern style of the adapter.
On the other hand, you could do Point(OtherPoint constructorParameter) to receive an OtherPoint object. The idea is similar: the Point methods now don't delegate to the methods it received via inheritance but to the object it received as a parameter in the constructor. This is the object pattern style of the adapter. This is a comparable to the wrapper pattern.

How does that explain the GoF statement(s)?

"Class patterns [...] are static-fixed at compile-time.

By saying Point extends OtherPoint you say that a Point is a OtherPoint. It's a plain old simple inheritance chain. You cannot change them at run time.

Object patterns [...] which can be changed at run-time and are more dynamic

By saying Point(OtherPoint constructorParameter) you say that a Point has a OtherPoint. Maybe you find out that this library has an even fancier class, i.e. FancierOtherPoint extends OtherPoint. You can pass that to Point as well. In fact you can pass any sublcass of OtherPoint to Point, because of polymorphism.

Maybe FancierOtherPoint only works on certain hardware and you have to check for that hardware at run time. With the object pattern style of the adapter, you can do exactly that: decide dynamically what class to use.

I've never heard of "object relationships" outside of this book.

"object relationships" is not special phrase. It means exactly what is says: relationships between objects. Design patterns are just names for common ways to define relationships between objects.

If I were to say "3.14159265359..." you'd probably stop me to ask if I mean "pi". Now if you were to tell me you "inherit from that one class to make things compatible and delegate methods and..." I would stop you to ask if you mean the adapter pattern.

It simplifies communication and everybody has a rough understanding of what the conversation is about without explaining everything in full detail.

Related Solutions

Factory Pattern vs Abstract Factory – What Is the Difference Between the Factory Pattern and Abstract Factory?

The Factory Method is usually categorised by a switch statement where each case returns a different class, using the same root interface so that the calling code never needs to make decisions about the implementation.

Think of a credit card validator factory which returns a different validator for each card type.

public ICardValidator GetCardValidator (string cardType)
{
    switch (cardType.ToLower())
    {
        case "visa":
            return new VisaCardValidator();
        case "mastercard":
        case "ecmc":
            return new MastercardValidator();
        default:
            throw new CreditCardTypeException("Do not recognise this type");
    }
}

The Abstract Factory is where you have multiple concrete factory classes (not Factory Methods) derived from one interface which may return many different types from different methods.

Think of a chess game manager with a different class for each set of variant rules.

public class StandardChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new StandardChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new StandardChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new StandardMoveClock();
    }
}

public class HexagonalChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new HexagonalChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new HexagonalChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new StandardMoveClock();
    }
}

public class SpeedChessRulesFactory : IChessRulesFactory
{
    public IBoardMapper GetBoardMapper()
    {
        return new StandardChessBoardMapper();
    }

    public IKingMover GetKingMover()
    {
        return new StandardChessKingMover();
    }

    public IMoveClock GetMoveClock()
    {
        return new SpeedChessMoveClock();
    }
}

An Abstract Factory, much like a Strategy, is often selected using a Factory Method, but it isn't necessary to combine them so it is its own pattern.

Design Patterns – Are They Independent of Programming Languages?

If I understand your question correctly, the answer boils down to this:

TLDR

The reason for having things like abstract classes and interfaces/protocols in a dynamic language like Objective-C are mainly simplicity and cleanliness of code.

The longer version

As cool as duck-typing is, it's actually a huge hassle if you cannot make any assumptions on the type of an object:
every respondsToSelector: line in your code messes it up. It adds noise that obfuscates what you are actually trying to accomplish for little to no benefit.

Besides, it's shit-work.

So if you provide an API contract by loosing some dynamism, using a more statically typed model it's almost always a win:

Replacing multiple respondsToSelector: methods with a single conformsToProtocol: is a win.
Having a succinct and clear listing of the necessary methods in the protocol definition is a win. (Writing that definition in and of itself is shit-work as well, but it keeps you from doing more shit-work in a number of places, so that's tolerable.)
Based on that, having the compiler warn you if you omitted implementing any one of those methods is a huge win.
And: Not having to write a single respondsToSelector: or conformsToProtocol: message at all, because the compiler can now warn and tell you where you messed up, is the biggest win of all.

If you can go further than that by providing a common foundation of actual implementation, creating an abstract class might be an even bigger win (probably not so useful in the context of delegation...) — after all, repeating yourself in implementation is the worst case of shit-work, as every change will result in more shit-work to keep things consistent.

So yes, dynamism is a cool and useful thing to have, as it allows you to pull off all kinds of fun tricks. But in practice, getting rid of some of that (where appropriate) can make your life much easier and keep you from doing shit-work — like writing respondsToSelector:.