C ++：如何对同一数据类使用不同的方法实现？

Question

Background: Various modules of the program I'm involved with deal with the same combination of objects that are grouped together in an aggregating structure. There are well-known invariants imposed on that combination of objects, and those invariants are respected by all modules to the fullest extent. Each module is developed by a dedicated team, and each team needs their custom domain-specific methods to deal with that combination of objects.

Example: To give you a tangible idea, imagine a sequence container class. The core of the container is the same across all users: it consists of data members for the storage, size/capacity and the allocator. But the set of methods, the contract and the body of those methods may vary a lot. One module may implement std-style operations, another module may implement all operations as nothrow methods, yet another module may insist on using their private checked iterators; some performance-critical module takes pain to ban all copy operations, while yet another module is all for making copies... Such requirements are well justified in each particular domain of any given module.

Speculations: So, providing a single non-redundant set of methods which would satisfy the needs of all the client teams is impossible - requirements of some teams are mutually exclusive. Providing only those methods that are commonly required by all modules is rather useless, because the only common part is, probably, the destructor. Throwing together all possible implementations of all methods is not good either: poor maintainability and stability, confusingly bloated interface, lots of name clashes, lots of cross-module dependencies.

The question: What options do I have to let several independent implementations operate on the same set of data members?

Things I tried: Solutions I can see thus far aren't exactly nice, and I ain't entirely happy with any of them. I'll list them in answers, three approaches one by one.

Answer 1

A possible less-than-perfect solution to my own question:

1. Don't bother with methods and have freestanding functions instead.

struct CoreData
{
    int   m_x;
    ~CoreData();
};

void TeamA_init(CoreData& data);
void TeamA_push_back(CoreData& data, Whatever args);
Iter TeamA_begin(CoreData& data);

bool TeamB_init(CoreData& data, Other args);
bool TeamB_push_back(CoreData& data, Whatever args);
X* TeamB_begin(CoreData& data);

//---------------------  Usage:
void ServiceOfTeamA::CallServiceOfTeamB(ServiceOfTeamB* srv)
{
    CoreData     d;
    TeamA_init(d);
    srv->Process(&d);
    TeamA_begin(d);
}

void ServiceOfTeamB::Process(CoreData* d)
{
    TeamB_push_back(*d, 567);
}

- What I don't like about this approach is unfriendly syntax, no RAII and all data members being public. That's C, not C++.

+ On the bright side, this approach offers unlimited customization possibilities. No restrictions on choosing the right function for the task. No memory overhead, no runtime overhead (that is technically, the compiler have the same inlining and optimization opportunities as it would have would those free functions be methods).

Answer 2

A possible less-than-perfect solution to my own question:

2. Have a set of classes that operate on an external instance of core data by reference.

struct CoreData
{
    int   m_x;
    ~CoreData();
};

class TeamA
{
public:
    // Allocates a new instance and owns it.
    TeamA();

    // Attaches an external instance without assuming ownership.
    TeamA(CoreData& ext);

    // Release the core, if must.
    ~TeamA();

    void push_back(Whatever args);
    Iter begin();
    CoreData& GetCore();

private:
    CoreData*     m_core;
    bool               m_doIOwnThatCore;
};

class TeamB
{
public:
    TeamB();
    TeamB(CoreData& ext);
    ~TeamB();

    int push_back(Whatever args);
    CoreData& GetCore();

private:
    CoreData*     m_core;
    bool               m_doIOwnThatCore;
};

//---------------------  Usage:
void ServiceOfTeamA::CallServiceOfTeamB(ServiceOfTeamB* srv)
{
    TeamA        d;
    srv->Process(d.GetCore());
    d.begin();
}

void ServiceOfTeamB::Process(CoreData* core)
{
    TeamB        d(core);
    d.push_back(567);
}

- What I don't like about this approach is that it imposes slight pessimization in terms of memory usage and performance. Also the syntax makes objects of type TeamA and TeamB look like values, while actually they have reference semantic.

+ Good news is that this approach allows somewhat better C++ syntax for the calls (but still, there's that ugly GetCore()), and meets RAII.

Answer 3

A possible less-than-perfect solution to my own question:

3. Throw the code on the mercy of de-facto defined behavior of reinterpret_cast.

// This is a standard layout class.
// It is the only class with data members;
// derived classes never append new data members.
class CoreData
{
public:
    // Could be either explicit conversion function
    // or implicit conversion operator.
    template <typename Final>
    // requires <LayoutCompatibleWithCore Final>
    Final& As()
    {
        return reinterpret_cast<Final&>(*this);
    }

protected:
    ~CoreData();

    int      m_x;
};

// No extra data members appended. No extra invariants imposed.
// This class is also a standard layout type,
// fully layout-compatible with CoreData.
class TeamA : public CoreData
{
public:
    void push_back(Whatever args);
    Iter begin();
};

class TeamB : public CoreData
{
public:
    bool push_back(Whatever args);
    X* begin();
};

//---------------------  Usage:
void ServiceOfTeamA::CallServiceOfTeamB(ServiceOfTeamB* srv)
{
    TeamA        d;
    srv->Process(&d);
    d.begin();
}

void ServiceOfTeamB::Process(CoreData* core)
{
    TeamB&       d = core->As<TeamB>();
    d.push_back(567);
}

- However, such tricks are outlawed by the standard. So I have to decline this approach, too.

+ If it was legal, it would have offered the best syntax of the three, the syntax clearly showing the reference semantic, with RAII and no pessimization.

PS Invalidity of this approach puts me down. The whole point of layout compatibility seems to give the ability to communicate data between ABI-compatible processes or shared components. Too bad it doesn't allow communicating the data between parts of the same application...