Factory Design Pattern Extend

I am reading Head First Design Pattern and at chapter of Factory. I am thinking to change one my working code to implement it.

First I create IAction and ActionFactory with GetAction, from IAction I create UploadDatabase, CopyFile, UploadSharepoint, etc. This is in DLL and can be call from a exe. This is easy and done.

Then I plan to create AutoCADAction from IAction which include action like Print, Script, etc. Those actions only can be run inside AutoCAD.

Now I like to create AutoCADActionFactory with override GetAction, it will creaet ActionFactory's, and AutoCADAction as well. Now I lost.

Here is the sample code:

In ActionFactory.GetAction

public IAction GetAction(ActionType myActionType)
{
    switch (myActionType)
    {
        case ActionType.UploadDatabase:
            return new UploadDatabase();

        case ActionType.CopyFile:
            return new CopyFile();

        case ActionType.UploadSharepoint:
            return new UploadSharepoint();
    }
}

How I code my AutoCADActionFactory.GetAction, Is 开发者_StackOverflow社区this correct?

public AutoCADAction GetAction(ActionType myActionType)
{
    return Base.GetAction;
    switch (myActionType)
    {
        case ActionType.Print:
            return new Print();

        case ActionType.Script:
            return new Script();

        ...

    }
}

Thank you,

I'm not completely convinced that a Factory, or more correctly a Factory Method (as you appear to be trying to use it) is the correct choice here. The reason I say that is you seem to have overlooked some things.

Typically, a Factory Method makes most sense when you will be performing operations that are doing similar things - for example reading a bitmap image from a file in various formats. The actions you have defined seem to vary widely, and I'm not convinced they should represent the same type of operation (i.e. support the same interface). Of course, there is no reason why your actions shouldn't support multiple interfaces (e.g. the Print class may implement both IAction and IPrint), but without additional information, I do wonder if the underlying design is as solid as it should be.

Because you are using the same ActionType enumeration in the ActionFactory and the AutoCADActionFactory you probably want / need to define a "null" action that is returned by the ActionFactory. (Depending on the context, you may want that null action to do something useful - like pop up a message box saying "That operation is not supported in this context", but it could just as easily do nothing at all.) The null action should be returned in the "Default" case.

As currently coded, you will always return the action from the base class. You probably want something that looks more like this:

public AutoCADAction GetAction(ActionType myActionType)
{
    switch (myActionType)
    {
        case ActionType.Print:
            return new Print();

        case ActionType.Script:
            return new Script();

        default:
            return base.GetAction(myActionType);
    }
}

This would allow you to completely replace the action provided by the ActionFactory (which I imagine would be the most likely thing to want), or to do specialized things like returning a specialized action which performs some specific operation in addition to the action from the base class.

You may also want to consider the common Object Oriented principle to "Favor Encapsulation over Inheritance". In this case, I don't see any real benefit in inheriting from ActionFactory. In the case of an Abstract Factory class, where there are separate calls for each action type, inheritance provides greater benefit.

Does any of this help?