Question

将不同职责放在一起的代码。代码更短，看起来更容易使用。

// Base class.
class A
{
public:
    // Native responsibility.
    virtual void F();

    // Show it with graphics.
    virtual void ShowGraphics();

    // Show it with table.
    virtual void ShowTable();

    // IO
    virtual void Read();
    virtual void Write();
};

// A number of concrete classes derive from base class.
class B : public A
{
public:
    // Native responsibility.
    virtual void F();

    // Show with graphics.
    virtual void ShowGraphics();

    // Show with table.
    virtual void ShowTable();

    // IO
    virtual void Read();
    virtual void Write();

private:
    // Include attributes required for native responsibility. 
    // Include attributes required for showing with graphics. 
    // Include attributes required for IO. 
    // Include attributes required for showing with table. 
};

使用图形责任作为示例分离职责的代码。代码要长得多。这真的值得吗？

class AGraphics;
class BGraphics;

class A
{
public:
    // Native responsibility.
    virtual void F();

    // Create AGraphics for showing with graphics.
    virtual AGraphics* CreateGraphics(); // ShowGraphics() becomes
                                         // CreateGraphics().Show().
                                         // For IO and showing table
                                         // do similarly.
                                         // Is this design okay???

    virtual ATable* CreateTable();                                             
    virtual AIo* CreateIo();                                             
};
// for the above code, does a follow singe responsibility principle?

class B : public A
{
public:
    // Native responsibility.
    virtual void F();

    // Create AGraphics for showing with graphics.
    virtual BGraphics* CreateGraphics();
    virtual BTable* CreateTable();                                             
    virtual BIo* CreateIo();                                             

private:
    // Include attributes required for native responsibility.
};

class AGrahics
{
public:
    // Show with graphics.
    virtual void ShowGraphics();
};

class BGrahics : public AGrahics
{
public:
    // Show with graphics.
    virtual void Show();

public:
    B* b; // need B's data attributes.
    // Include attributes required for showing with graphics. 
};

Answer 1

1）取决于实施。如果实现简单易懂，那么您可能希望将它们保存在一个类中以降低复杂性。但是，如果实现很大且复杂，那么您可能希望将其分成不同的类以降低复杂性 2）取决于使用情况。尝试编写单元测试并相应地重构接口。应该很容易分别测试各种功能。如果它易于测试，则很容易重复使用。

Answer 2

Gamma等人出版的优秀“设计模式”一书讲述了可能会更改的事情与不太可能发生变化的事情之间的隔离。一般来说，代表某事物（图形，表格）的方式的代码将比事物本身的代码更频繁地改变。

因此，将问题分成不同类的麻烦的一个原因是，你最终会得到一些较小的类，每个类都做得很好。稍后，如果您决定向表输出的外观添加功能，例如，您不必浏览有关IO和图形的所有代码。（如果这些类是分开的）使用包含似乎是额外的工作，但它有助于澄清你对这个问题的思考 - 它避免了当你不小心在一部分中使用类变量时出现的令人讨厌的问题。影响另一部分行为的代码。

哪一个更好，拼凑或分开一些成本？

2 个答案: