Factory Method Pattern – How to Use Correctly?

design-patterns

I'm currently re-designing my hobby project and I'm trying to apply what I've learned recently from design patterns. Summary for context: the project listens for TCP commands from my phone (using another project not related to this question) and controls my PC using the Win32 API. This question concerns the Windows application.

Current design of the project

As you can see, I have already used the Command pattern to generalize what actions the TCP listener provides. It works well, although I'm not certain whether the ToggleShaderCommand should keep a state. I decided for it to have a state because it's a toggle and it's the command's responsibility to take care of calling the right operation (ClearShader/SetShaderUpscale).

Window is not an abstract class, because some other objects may create a Window using just a handle.

Now what I'm trying to do is use the Factory Method pattern, because of the lifetime of the Window objects. They sometimes get created (a new handle is found), but sometimes returned from cache. Furthermore, more Window classes may be added in the future with new possible actions.

My attempt at using the Factory Method pattern

As you can see, I separated the window interaction logic into different classes. The Window classes now only hold the state (the window handle and possibly other data in the future).
The responsibility of the WindowInteraction classes is to interact with their respective windows and to keep track of the Window objects and their caching.

Is the Factory Method pattern useful in this situation from the information I provided? If so, do I implement it correctly or is this design creating some future problems?

Here is the link for the diagram.

Best Answer

Factory Method Pattern Overview

The Factory Method pattern as originally presented makes most sense in the context of frameworks that let you derive your own classes from framework-provided base classes. E.g. the framework provides a Window class, and you derive MyWindow from it.

Sometimes, a framework has some setup procedure, or provides some functionality, and as a part of that, it needs to instantiate an object, but it can't know its concrete type, because the object is supplied by a consumer of the framework (anyone can derive a class, and the framework must be written independently of that).

So, the idea is to provide a virtual creator method that a derived class can override and supply the appropriate instance. E.g. inside the Window base class, the framework can just say this.CreateContextMenu(), and inside MyWindow, you can create an application-specific context menu on demand by overriding that method. It's a "virtual constructor".

But the core of the pattern is really that virtual method: some kind of an abstract creation operation, that you can supply your own version of. Most languages today support lambdas, so if you only need one kind of creator, you can just inject a lambda as a dependency. Or, you could have public creator methods that other classes can make use of - e.g. a higher-level class can ask an object to create a related object (of a certain subclass) in an abstract way. The exact form of the pattern isn't what makes the pattern; it's all about the major elements and the roles they play to fulfill the intent behind the pattern.

The central question: Do you have clients that need abstract creators?

I can't answer this for you because I don't know enough about your system, and it's not entirely clear from your question. Figure out who calls GetWindow() and why - and how abstract the context is.

If your WindowInteractor contains high-level logic that at some point needs to create/obtain a window without knowing its concrete type, then some variation of the Factory Method seems like a good fit. It also works if some other code that only knows about the abstract WindowInteractor type needs to ask an interactor for a window, and can't know the concrete type of the window (here, factory method connects parallel hierarchies, without the client being aware of them). Also, some objects could potentially get injected with a window-providing lambda that either creates a window or supplies the cached instance. There are different options.

If there isn't an aspect to it that can be described along these lines, then there's no Factory Method in there. Your commands seem to reference the derived interactors directly, so the call to GetWindow() is not polymorphic; this is not wrong in itself, but is not exactly Factory Method - perhaps your WindowInteractor is predominantly used for implementation inheritance, while the interface inheritance aspect of it is more of a "bookkeeping" mechanism (ensures that interactors consistently implement GetWindow(), but isn't meant to be used in a polymorphic way). Again, this is all pretty general, but I hope you'll find it useful to assess your particular case.

Future problems?

Is the Factory Method pattern useful in this situation from the information I provided? If so, do I implement it correctly or is this design creating some future problems?

Every design is potentially creating a future problem; a design that's amenable to a certain set of changes is rigid for other kinds of changes. Generally, when making design decisions, try to recognize the tradeoffs you're making, and then come up with something that works well for the domain as you currently understand it, while being conservative in order to avoid building into your code too many assumptions that are hard to reverse later (in the spirit of principles like YAGNI and KISS). This is because you'll learn more about the system as you go along, and your cost/benefit analysis of the tradeoffs will change; you need to be able to react to that - and eventually arrive at a design that's better suited to your actual system.

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.

Php – Should I use the factory design pattern for every class

Of course not.

The factory pattern is useful if you need to encapsulate create-time polymorphism from consumers, that is, you want to provide a transparent point from which new instances of a polymorphic type are created.

If the type in question is not polymorphic, the factory pattern is pointless.

If a single point of creation doesn't make sense, neither does the factory pattern.

If it is undesirable to hide the polymorphism details away, the factory pattern is probably inappropriate, too.

As with anything that adds complexity, you should default to not using it, but spot the point at which it is beneficial early on and apply it before it is too late.

Also, consider this: If you use a factory for everything, who creates the factory? Another factory? And who creates that?