3

背景のビット:

私は現在、さまざまな設計パターンに基づいて電話帳マネージャーを設計および実装する OOP コースの課題に取り組んでいます。

私のプロジェクトには、すべてのアクションが発生する 3 つのクラスがあります。

  • PhoneBook;
  • Contact (電話帳に保存されているタイプ);
  • ContactField ( に格納されているフィールドContact)。

ContactManager2 つのモードで連絡先を反復処理する方法を提供する必要があります。述語に基づいてフィルター処理されていないモードとフィルター処理されています。Contactフィールドを反復処理する方法を提供する必要があります。

私が最初に実装することにした方法：

私が出会ったすべてのデザイン パターンの本は、インターフェイスへのコーディングを推奨しているため、最初に考えたのは、上記の各クラスからインターフェイスを抽出し、それを実装することでした。

ここで、物事を円滑に進めるためにある種のポリモーフィック イテレーターも作成する必要があるため、Java イテレーター インターフェイスを順方向イテレーターを記述するように適合させました。

問題点：

  • この設計の主な欠点は、stl<algorithm>との相互運用性と、範囲ベースの for ループによって提供されるシンタックス シュガーが失われることです。

  • 私が遭遇した別の問題はIterator<T>::remove()機能です。反復するシーケンスを変更できる (要素を削除する) イテレータが必要な場合は、すべて問題ありませんが、その動作が必要ない場合は、何をすべきか正確にはわかりません。

    Java では、例外が処理されない場合はアプリケーションが終了し、スタック トレースが表示されるため、それほど悪くないスローが可能であることがわかりますUnsupportedOperationException (間違っている場合は訂正してください)。C++ では、(デバッガーを接続して実行しない限り) そのような贅沢は実際にはありません。正直なところ、コンパイル時にそのようなエラーをキャッチしたいと思います。

この混乱から抜け出す (私が見た) 最も簡単な方法は、独自の stl 互換イテレーターに対応するために、反復可能な型でインターフェイスを使用しないようにすることです。これにより結合が増加しますが、長期的に実際に影響があるかどうかはわかりません (もちろん、このプロジェクトがすぐに使い捨てコードになるという意味ではありません)。私の推測では、そうはならないでしょうが、設計を進める前に、長老たちの意見も聞きたいと思います.

4

1 に答える 1

1

私はおそらく少し異なるアプローチを取るでしょう。

まず、連絡先の反復は非常に単純です。これは反復の単一のタイプであり、基礎となるフィールドの反復を許可するメソッドをbegin提供するだけでよいからです。end

の反復では、通常のandを提供し、興味のない要素をスキップするスーパー カスタム イテレータを提供しようとする代わりに、関心のある連絡先のみを反復処理するために使用する関数を提供しPhoneBookます。beginendfor_each_if

于 2013-05-13T19:52:37.393 に答える