2

デザインパターンクラスの場合、インストラクターは私のチームに、GoFのWYSIWYGエディターと非常によく似た、グリフの描画と永続化をサポートするアプリケーションの開発を依頼しました。

私のチームは、プレゼンテーション、コントローラー、ロジック、永続性という降順のレイヤーを備えたレイヤードアーキテクチャを使用することにしました。

ロジックは、グリフ表現のコレクション、それぞれの位置、およびいくつかの形状固有のプロパティを維持します。CSVとXMLは永続化形式である必要があるため、インストラクターはBuilderパターンを使用して統一された永続化メカニズムを作成することを提案しました。

この問題は、永続層内でビルダーを設計しようとしたときに発生します。レイヤーを使用しているため、永続レイヤーはGlyphタイプについて明示的に知ることはできません。ましてや、それらを抽象的な形から個々の形にキャストすることもできません。これにより、各Builderをコンストラクターとして渡すものについて頭を悩ませています。

次の問題は、Builderが使用するタイプを一般化するのが難しいことです。長方形には、線にはないプロパティがあります。

私はこれを行う方法を理解するのに多くの問題を抱えています。Builderのパターンは理解していますが、何かがクリックされていません。パターンを誤用していますか、それとも問題に正しく適合していませんか？

編集：インストラクターは、永続化されたフォーマットを再度ロードする必要があるとは言いませんでした。私の終了ソリューションは明らかにこれを簡単にするはずですが、現在の問題では、保存にのみ焦点を当てています。

4

1 に答える 1

2

これにはビルダーが必要かどうかわかりません。ファクトリ/レジストリとシリアル化可能性は、おそらくより重要です。

特定のグリフ インスタンスを保存およびロードする機能を与えながら、明示的なグリフ タイプを認識しない永続レイヤーを作成する方法は、何らかのリフレクションメカニズムを使用することです。言語に組み込まれているもの (.Net のリフレクション、Delphi / C++ Builder の RTTI など)、または自分で作成したもの。

ソリューションを自分で作成するには、すべてのグリフ タイプを共通の「シリアル化可能な」基本型から派生させるか、それらすべてに「シリアル化」インターフェースを実装させる必要があります。永続化レイヤーは、この基本タイプまたはインターフェース (選択した方) についてのみ知る必要があります。

インターフェイスを使用するということは、すべてのグリフが共通の基本型を必要としないことを意味します。共通の基本型を使用するということは、その基本型に共通の動作を実装し、重複を避けることができるということです。

「シリアル化可能な」基本型またはインターフェイスは、一意の (文字列) ID によってグリフ型を識別する手段、永続化/ロードされるプロパティを反復処理する手段を永続化レイヤーに提供する必要があります。そして、ポリモーフィックにグリフをインスタンス化する手段 (Delphi の仮想コンストラクタとメタ クラスが話します)。

インスタンスを保存するには、グリフ タイプ ID を取得し、永続化するプロパティを反復処理するだけで十分です。

プロパティの反復処理は単純明快ですが、これを「デザイン パターン化」したい場合は、Visitorの使用を検討できます。これは、グリフ (描画アプリケーションでのグループ化) を構成して集約すると、生活がずっと簡単になるかもしれませんが、しゃれは意図されていません :-)。それに関しては、Compositeパターンを検討することも考えられますが、それはあなたが求められていることに対してやり過ぎかもしれません。

永続ストアからグリフをロードするには、グリフ タイプが一意の名前 (文字列) にリンクされている場所にレジストリが必要です。これにより、永続レイヤーは、永続化された情報の文字列からインスタンス化するタイプを検索できます。各グリフ タイプは、永続化レイヤーによって検出およびインスタンス化できるように、レジストリに登録する必要があります。詳細については、ファクトリ メソッドと抽象ファクトリパターンを参照してください。

于 2010-09-22T06:34:17.147 に答える