0

ネストされた順序付けられていないhtmlリストを生成するクラスがあります。

class cTree {    

function cTree(){
}

public function getTree($id = NULL ){
}

private function addSubNode($iParentId, $iLevel){
}

addSubnode は、ネストを正しく行うための再帰関数です。

今、私は自分のウェブサイトに 2 つのナビゲーション メニューを用意したいと考えています。どちらも順不同のリストですが、マークアップが異なります。

私が見たように、3つのオプションがあります：

  1. getTree() と addSubNode() に追加の変数を渡し、if/else 構造を使用します。メンテナンスができないので、私はそれが好きではありません。

  2. クラスに 2 つの関数を追加します。たとえば、getTopTree()/ getFooterTree と addTopSubNode()/ addFooterSubNode(); を作成します。

  3. 2 つの新しいクラスを作成し (class cTopMenu extends cTree / class cFooterMenu extends cTree )、好みに合わせて getTree/addSubNode を編集します。

前述のとおり、1 番目のオプションは好きではありませんが、2 番目と 3 番目のオプションについてはわかりません。最適なデザインの選択は何でしょうか?

状況をより明確にするための追加の例。上記と同じではありませんが、間違いなく比較できます。ナビゲートするためのツリーがあります：

<ul>
  <li><a href="/x">Item 1 </a></li>
  <li><a href="/x">Item 2 </a></li>
  <li><a href="/x">Item 3 </a></li>
</ul>

次に、管理オプションを備えた別のものがあります。

<form method="post">
 <ul>
   <li>
       <input type="text" value="Item 1" />
       <input type="checkbox" value="1" id="visible_1" name="visible[]"> 
       <label for="visible_1">&nbsp;visible</label>           
   </li>
   <li>
       <input type="text" value="Item 2" />
       <input type="checkbox" value="1" id="visible_2" name="visible[]"> 
       <label for="visible_2">&nbsp;visible</label>           
   </li>
   <li>
       <input type="text" value="Item 3" />
       <input type="checkbox" value="1" id="visible_3" name="visible[]"> 
       <label for="visible_3">&nbsp;visible</label>           
   </li>
 </ul>
</form>

基本的に同じ木です。今のところ、getTree() 関数と addSubNode() 関数を置き換えて、基本的なツリー クラスを拡張しました。

4

1 に答える 1

0

アプローチを提案するために、予想される 2 つのマークアップを教えていただければ非常に助かります。私は部分的な答えを試すことができると言った：

  • あなたが言ったように、最初のオプションは良い方法とは思えません。これは、クライアントで何をすべきかを決定する責任があるためです (つまり、if/then/else 部分)。これにより、多くの場所でそのステートメントが繰り返され、テストと保守性の問題が発生します。
  • 2 番目のアプローチで見られる問題は、これを行うと、cTree のインスタンスがツリーを表すのではなく、ある種の関数のツリー コレクションになることです。その結果、いくつかの OO 構造を使用することになりますが、OO パラダイムに固執することはありません。また、後で新しいタイプのツリー (サイドバー ツリーなど) を作成することにした場合は、新しい関数セット ( getSideTree()/ addSideSubNode()) を追加する必要があることも考慮してください。これもスケーリングされません。

私見の問題は、ケースごとに特定のサブクラスを作成してこのケースを処理する必要があるかどうか、またはそれらがcTree別のオブジェクトと協力して目的の出力を取得する 2 つのインスタンスにすぎないかどうかです。前に述べたように、予想される 2 つの出力を知らずに判断するのは困難です。

編集 新しい情報に基づいて、両方のアプローチ (サブクラス化または構成) が有効であると思います。

  • サブクラス化。cTreeノードのレンダリング以外のすべてを行う抽象クラス ( ) があります。これを行うメソッドは抽象的であり、具体的なサブクラス (topTreeおよびfooterTree) がこれを処理します。テンプレートメソッド patternを見たいと思うかもしれません。
  • 構成。ここでは、ツリー構造のレンダリングを担当し、ノードのレンダリングを別のオブジェクトに委譲する 1 つのツリー クラスしかありません。その他のオブジェクトは、別の階層でモデル化されます (たとえば、とtreeNodeを持つ抽象クラス)。ツリー間の違いは構造ではなくノードであることが明確に示されているので、私はこれが好きです。topNodefooterNode

ご覧のとおり、2 番目のオプションは、サブクラスでオーバーライドされたメソッドの実装をポリモーフィック オブジェクトの階層に変換することです。どのオプションを使用するかは、レンダリング プロセスの複雑さと個人の好みによって異なります。

HTH

于 2012-12-05T19:45:01.297 に答える