Метод ограничения доступа к определенному классу

Question

class A : public Interface 
{ 
public: 
    void doAction(); 

    void interfaceMethod1(); 
    ... 
} 
class AExt 
{ 
public: 
    void doAction(); 
private: 
    int m_state; 
} 

У меня есть класс A, который может делать Action(), а также реализацию интерфейса (интерфейс не включает doAction). Работа прекрасна, поэтому я хотел бы свести к минимуму изменения в A. Теперь я хочу добавить новое состояние и создать класс AExt, который теперь берет на себя ответственность за создание doAction(), который изменяет состояние и теперь зависит от состояния. Цель состоит в том, чтобы ограничить doAction() так, что он может быть вызван ТОЛЬКО с помощью AExt, потому что вызов A :: doAction не из AExt нарушит функциональность. В то же время Aext использует только публичный интерфейс А.

1. я могу сделать DoAction() частный и сделать Aext друг A, но мне не нравится это, потому что он выставит внутренности всех А к Aext;
2. Я могу сделать doAction() виртуальным и наследовать AExt от A, той же проблемой. Кроме того, будет (probabaly) быть преемником, который не хочет знать, есть ли A или AExt.
3. Я могу использовать тот же интерфейс для A и AExt и использовать шаблон Decorator, но мне это не нравится, потому что у A есть много дополнительных методов (весь интерфейс), которые AExt не нужен, и им нужны клиенты A.

4. Я могу использовать состав следующим образом: , но это не помешает вызову A :: doAction() извне.

   class AExt { public: void doAction() { m_a.doAction(); ... } A& getA() { return m_a; } }

предложения?

Answer 1

Владелец, C++ не обеспечивает точную детализацию, которую вы хотите. Вы в основном правы со своими подходами 1-4. Попытка добавить такие мелкие детали в C++ приведет к еще более сложному языку. Некоторые говорят, что C++ уже слишком сложна. Это означает, что языковой дизайн - это торговля между выразительностью и желанием сохранить ее достаточно простой.

Я бы объявил, что ваш doAction(); защищен. Это запретит называть его произвольным кодом. В то же время кажется, что AExt - это ваш собственный класс. Возможно, это не так ужасно плохо, если у него будет полный доступ к его родителям. Это решение не является совершенным со всех точек зрения. Главное преимущество - простота. Я бы порекомендовал вам не слишком усложнять свой код без веских оснований для этого. Простота и ясность кода также важны.