メンテナンスとカプセル化のためのC++クラスの階層構造

Question

カプセル化に関する一般的な質問は、保守性に関するものです。ここでは、解析ツリーの構築を支援するために使用したクラスの例を示します。 （私は教育のためにSTLを避けました）

Nodeクラスは、ツリー内のノードを記述します。管理クラスParseTree（図示せず）は、Nodeオブジェクトのコレクションを意味のある木のような方法で構築および維持する責任があります。

// contents of node.h, not including header guard or namespace 
class Token; 
class Node { 
public: 
    static const Node* FindParent(const Node* p_root, const Node* p_node); 
    static int Height(const Node* p_root); 
    static void Print(const Node* p_root); 
    Node(const Token * p_tok=0) : p_left_(0), p_right_(0), p_tok_(p_tok) {} 
    ~Node() { delete p_left_; delete p_right_; } 
    const Node* p_left(void) const { return p_left_; } 
    const Node* p_right(void) const { return p_right_; } 
    const Token* p_tok(void) const { return p_tok_; } 
private: 
    friend class ParseTree; 
    Node* p_left_; 
    Node* p_right_; 
    Token* p_tok_; 
}; 

次の4つのトピックは、カプセル化に関連しています。彼らは任意のプライベートメンバーを使用せずに言うこともできるので、Nodeクラスの

1. 静的メソッドは、静的に宣言されています。私は彼らが共通の名前空間にNodeの外に住んでいなければならないのか、あるいはParseTreeの中の静的なメンバーとして住んでいるのだろうと思います。私の決定は、ParseTreeが木を担当しているという事実によって支配されるべきであり、その論理によって関数はParseTreeに生きるべきですか？

2. 関連するメモでは、ParseTreeの代わりに、静的メソッドがNodeである理由は、ParseTreeが多数のメンバーでいっぱいだったためです。私は、クラスを小さく保ち、敏捷性が保守性に優れていると読んでいます。プライベートメンバーのアクセスに依存しないメソッドを見つけ出し、それらをクラス定義から取り除き、それらをクラスと同じ名前空間内にグループ化された関数に入れる方法はありませんか？

3. 私はまた、カプセル化を破る傾向があるので、プライベートメンバーにミューテータを避けに関するいくつかのアドバイスを読んでいたので、私は唯一のアクセサを持つことになった、とParseTreeはNodeとの友情を使って任意の変更を処理してみましょう。これは実際に突然変異を持っているだけでなく、ParseTreeで友情を終わらせるよりも本当に良いですか？ミューテータを追加すると、Nodeは別のフレンドシップを追加せずに他のコンテキストで再利用できます。

4. Nodeからミューテータを追加して静的関数を削除すると、データメンバーをパブリックにして、すべてのアクセサ/ミューテータ/フレンド宣言を削除できたようです。私はそのようなアプローチが悪い形であるという印象を持っています。プライベートメンバーごとにアクセサー/ミューテータのペアがある場合は、私のデザインに懐疑的なはずですか？

5. 私のアプローチについて他に何か尋ねると思わなかったことがあれば、それについて聞いていただければ幸いです。

Answer 1

ノードとは何ですか？明らかに、それは親、左の子、そして右の子を持つかもしれないものです。それはまた、いくつかのデータへのポインタを保持します。ノードには高さがありますか？コンテキストに依存しますが、ノードがある時点でサイクルの一部になる可能性がありますか？ ParseTreeは高さの概念を持っていますが、それはノードのようには見えません。

正直言って、あなたのプログラムのロジックを正しいものにしてから、オブジェクト指向の鐘や笛を心配することをお勧めします。 あなたの質問はあなたが進むにつれて答えるでしょう。

Answer 2

私はノードは明らかにあなたのプライベートメンバーを露出させるだけの間接的な方法であるこれらのアクセサ、と少しも混雑していると思います。私はこれらの静的メンバーをアプリケーションの名前空間に取り除くのが少し面倒だと思います。例：

namespace mycompiler { 
    class Node { 
     ... 
    }; 

    class ParseTree { 
     ... 
    }; 

    const Node* FindParent(...); 
    int Height(...); 
    void Print(...); 
} 

このようにして、グローバル名前空間を汚染することなく、ノードとParseTreeクラスを小さく保つことができます。 mycompiler::の機能（たとえばPrint()）の一部をオーバーロードして、名前空間のオブジェクトをクラスに貼り付ける必要がない場合は、受け入れることもできます。これにより、NodeおよびParseTreeはよりインテリジェントなコンテナになりますが、（関連するクラスへの）外部ロジックは、mycompiler::に分離できます。