Question

The code to put different responsibilities together. Code is shorter and seems easy to use.

// 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. 
};

Code to separate responsibilities using graphics responsibility as an example. Code is much longer. Does it really deserve it?

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

The excellent “Design Patterns” book by Gamma, et al, talks about isolating things that may change more often from things that are less likely to change. Generally speaking, code for the way you represent something (graphics, table) will change more often than code for the thing itself.

So one reason to go to the trouble of separating the concerns into different classes is that you end up with smaller classes that each do one thing well. Later, if you decide to add a feature to how the table output looks, for example, you don’t have to wade through all the code about IO and graphics. (if the classes are separate) It seems like extra work to use containment, but it has the side benefit of helping to clarify your thinking about the problem – and it avoids nasty issues that come up when you accidentally use class variables in one part of the code that affect behavior in another part.