0

抽象クラスとインターフェースに関する多くの質問を読んだ後、コードの設計をどのように進めるべきかまだわからないので、重複の可能性を見逃すリスクを冒して、これが私の状況です。

私は、特定のタイプのオブジェクトの厄介な階層を処理することを目的としたいくつかのユーティリティクラスに取り組んでいます。オブジェクトの正確な詳細は関係ありませんが、それは一般的な解決策ではないと言えば十分です。CustomNodeそれで、私はとCustomHierarchyクラスを書くことから始めました。

少し後になって、前述の複雑なクラスのモックインスタンスをたくさん作成しなくても、さまざまなコンテキストで再利用して簡単にテストできる、より一般的なソリューションを作成する方がはるかに賢明であることに気付きました。インターフェイスと抽象クラスのすべての一般的なコードを簡単に提供し、必要な場所に特定のビットを提供するだけで済みます。（これがOOPの要点だと思いますか？）

これまでのところ：

  • Relatableノードが相互に持つ可能性のある可能な関係の列挙を単に保持するインターフェース、およびgetRelation(Relatable other)

  • Node<E>を実装し、Relatableすべてのユーティリティメソッド（addChild()または。など）を含む抽象クラスgetNextSibling()。このクラスにない唯一のメソッドはgetRelation(Relatable other)。

  • データを保持するHierarchy<E>から始めて、ノードの階層を構築する方法を定義する具体的なクラス。Collection<E>

アイデアは、目前の問題に基づいて、Node<E>およびクラスを適切なサブクラスで拡張することです。Hierarchy<E>最初の2つは大きな手間をかけずに実行されますが、クラスをインスタンス化して階層に配置しようとするプライベートメソッドHierarchy<E>があるため、クラスに問題があります。ノードクラスは抽象的でインスタンス化できないため、これは明らかに失敗します。addNodeToHierarchy(E data)Node<E>

これが機能しない理由は理解していますが、この問題を回避する方法がわかりません。デザインに欠陥はありますか？に静的createNewNode(E data)メソッドを追加しNode<E>て、代わりにそれを使用する必要がありますか？私が考えることができるもう1つのオプションはNode、リレーションの取得から切り離して、Relator代わりにインターフェイスを使用することです。これは万が一特有の問題ではないので、この状況での「グッドプラクティス」とは何でしょうか。

前もって感謝します、

4

1 に答える 1

1

Node<E>のインスタンスからどのようにaを構築する必要があるかを誰が知る必要があるかを決定しますE。のインスタンスE、Nodeクラス、階層、またはの呼び出し元である可能性がありaddNodeToHierarchy()ます。

の呼び出し元の場合addNodeToHierarchy()は、のインスタンスのNode<E>代わりにのインスタンスをE取得するかNodeFactory<E>、メソッドがデータをノードに変換するために委任するいくつかのインスタンスを取得するようにします。すべてのノードが同じファクトリによって構築されている場合、このファクトリを階層コンストラクタに引数として渡すこともできます。

于 2012-08-10T10:02:51.003 に答える