Question

（这个问题没什么重要的）

我曾经读过这样一个“糟糕的应用程序架构”的例子：

有一个“渲染应用程序”（浏览器，据我记得），所以有人告诉我，在TagA，TagUL，TagDIV类中使用“render（）”方法是非常糟糕的做法，因为你会有很多“渲染代码”都被涂抹了。所以（在这个例子中），他们建议使用RenderA，RenderUL，RenderDIV类来实现渲染。标记对象会封装那些渲染器。

我无法理解为什么这是一种不好的做法。在这种情况下，我们会在Render- *对象周围涂抹许多渲染代码。而且，最后，为什么不使用Redner-singleton和许多覆盖方法呢？听起来，至少更便宜。

阅读什么更好地理解它？

Answer 1

所有这些不同对象的渲染是否相同？如果是这样，那么它应该只实现一次，最有可能在基类中实现。这将是一个比Singleton更好的解决方案，它有一个完全不同的目的：主要是实现一个只应存在一次的资源（注意它的资源，而不是方法）。

如果render（）的每个实现都不同（很可能是这种情况），那么在单独的对象中实现它们没有任何问题，这称为polymorphism。但是，应该做的是，有一个类层次结构，其中render（）方法在基类中定义（很可能是抽象的）并在派生类中实现。这有效地形式化了接口，这意味着从所述基类继承的任何类都将具有render（）方法，并且必须实现它。

如果渲染代码的一部分是常见的，并且部分特定于派生类，而不是必须复制所有派生类实现中的公共部分，则可以使用Template Method模式，基类方法执行公共部分，并协调调用派生类实现。这是C ++中的伪代码示例

class TagBase {
public:
    void render() {
        // do some common stuff here
        doRender();
        // do some more common stuff here
    }

    virtual void doRender() = 0;
    ....
};

class TagA : public TagBase {
public:
    virtual void doRender() {
        // do your specific stuff here
    }
};

以下是一些好书：

Answer 2

我无法理解为什么这是一种不好的做法。

如果标签不是自我渲染的责任，那可能是不好的做法 - 请参阅Single Responsibility Principle。

例如，如果Tag类已经包含HTML解析行为并且您向其添加渲染，那么它将具有2个职责，2个更改原因并可能中断。由于它们的搭配，解析将与渲染紧密耦合，这带来了许多问题：

您无法独立于其中一个职责更改或添加变体 - 例如，除桌面浏览器渲染外，添加移动浏览器渲染还需要编写另一个重复解析行为的类。规模较小，责任更集中，意味着更多的移动部件和更多的模块化。
一个类嵌入的责任越多，当您对其进行更改时，可能会出现更多错误和副作用。在许多情况下，很难分辨出哪两个责任导致了这个错误。
您必须重建，重新测试并重新部署课程中包含的所有职责，即使您只对其中一个进行了更改。
当其他职责可以干扰时，调试其中一项责任也更加困难。

OOP：应用程序架构问题

2 个答案: