工厂模式还是扩展方法？

Question

我正在研究设计模式，但是我不确定哪种方法更好：

我有一个“类别”类，其中有几个字段：名称，2种url，相关对象列表。 有一种方法“ toHtml（）”，该方法基本上从该类的实例生成一些HTML。

有4种类型的“类别”具有完全相同的字段，但“ toHtml（）”方法应为每种类型提供不同的结果。

我不确定是否应该传递参数“ type”和一系列的ifs / switch语句以生成不同的html，还是我应该对Category类进行抽象并创建几个覆盖toHtml（）方法的子类，然后使用CategoryFactory类生成它们？ 在这两种情况下，我都需要传递'type'参数。

我试图考虑“关闭以供修改，开放以供扩展”的OOP规则。 但是在这种情况下，如果我想添加“第五”类别类型，则会生成不同的html-对于第一个解决方案，我只需要修改toHtml方法（如果再添加一个），对于第二个解决方案，我需要创建其他子类，并且修改CategoryFactory类。

有什么更好的做法？ 当我遇到类似的困境时，我应该遵循什么额外的规则？

Answer 1

如果创建Category的子类并覆盖toHtml（）方法，那么为什么需要工厂模式。 如果使用引用调用运行时解析类的toHtml（）方法，则将调用该方法。 这意味着，如果添加一个新的Category子类，则可以重写toHtml（）方法，它应该可以正常工作。

Answer 2

首先，我相信您指的是工厂方法，而不是抽象工厂模式。

主要区别在于，前者为单个产品定义通用模板，而后者则为产品系列定义模板。 有关更多信息，您可以在这里查看 。

对于您的情况，您希望为Category定义一个模板。 在这种假设下，您的班级类别将如下所示：

abstract class Category {
    public void doSomething() {
        Foo f = makeFoo();
        f.whatever();   
    }

    abstract void toHtml();
}

class Category1 extends Category {
    public override void toHtml() {
        ... // do something here
    }
} 

class Category2 extends Category {
    public override void toHtml() {
        ... // do something else here
    }
} 

确实，这肯定是很多代码，并且可以很容易地表示为：

class Category {
    public void toHtml(Integer param) {
        if(param == 1) { // do something for Category1
        }
        else { // do something for Category2
        }
    }

归根结底，这实际上是一个设计决定。 您可以考虑一些因素。 这将是一个不断变化的阶层吗？ 是否将其声明为全局供客户使用？ 您希望客户如何使用它？

这时比较容易的事情是走阻力最小的道路。 为所有类别提供一个类别的服务肯定会减少代码，而在Salesforce中，减少代码始终是一件好事。 但是请考虑一下： 将您的功能抽象到单独的类中将使代码更易于维护 。 您可能会发现更容易地编写一个类的墙if当你不在身边的语句，但明天，有一个致命错误，有人看你的代码准确地找出其if导致问题的原因，他们会诅咒你。

请记住，继承是一种全有或全无的机制。 如果您具有某些常用功能，则可能会发现它特别有用，在这种情况下，您可以选择将其抽象到父类中，并让您的孩子照顾具体细节。