2

私は基本的にコードエディタである個人的なプロジェクトに取り組んでいます。[新規]、[開く]、[保存]、[名前を付けて保存]、[すべて保存]、[閉じる]、[すべて閉じる]のメニュー項目がある標準の[ファイル]メニューを想像してみてください。

私は適切なデザインにこだわっています。現在私は持っています：

  • ドキュメントを表すドキュメントクラス-コード編集コントロール、タブバーのそれぞれのタブ、およびキャプション、ファイル名、IsModifiedなどのさまざまなプロパティ。
  • 開いているすべてのドキュメントを表すDocumentsクラス。New、Open（FileName）、...などのメソッドが含まれています

問題は、どのクラス/メニューコマンドがどのタスクを担当しているかがわからないことです。

たとえば、[ファイル]->[新規]メニューコマンドは簡単です。Documents.Newを呼び出すだけです。

しかし、[ファイル]-> [開く]はどうですか？Documents.Openメソッドは、パラメーターとしてファイル名を想定しています。したがって、このメソッドを呼び出す前に、ファイル選択ダイアログを開き、ユーザーにファイルを選択させ、ファイルごとにDocuments.Open（FileName）を呼び出す必要があります。このサポートコードを配置するのに最適な場所は、メニューコマンドで、Documents.Openを書き直してそこに配置しますか？

保存アクションについても同じです。どちらが節約の責任がありますか？Document.Editor.SaveToFile（FileName）を使用するDocumentsクラスですか、それともDocumentクラスにSaveメソッドを作成する方がよいですか？途中のどこかで、ユーザーに現在のドキュメントを保存するかどうかを尋ねる必要もあります...

私は立ち往生しています。何か案は？

編集：プログラミング言語はDelphiです。

4

2 に答える 2

0

すべてのドキュメント操作を管理するシングルトンオブジェクト（DocumentManager）が必要です。これには次のような機能があります。

  • Get（idList）
  • GetNew
  • Save（docList）
  • 更新
  • 等...
于 2011-03-08T12:46:10.647 に答える
0

私見ですが、ドキュメントクラスに多くの責任を追加しています。Documentsクラスの唯一の責任は、関連する機能を備えたドキュメントのコレクションを維持することです（たとえば、同じドキュメントの複数のインスタンスを処理する、すべてのドキュメントが閉じているかどうかを確認する、子を数えるなど）。

ドキュメントを開くこと、または新しいドキュメントを作成すること（たとえば、フォーマットを選択する必要がある場合はどうなるか）は、最終的には新しいドキュメントになり、それがDocumentsクラスに追加される個別の操作です。私の意見では、Documentオブジェクトを渡す準備ができるまで、Documentsクラスを操作することすらすべきではありません。

UIを表現し、ファイルを作成または開くために必要なすべての情報を取得するためにユーザーと対話するためのクラスがあることを願っています。そこからすべてを処理する必要があります。それ以外の場合は、UI関連のものでモデルを汚染していることになります。

于 2010-01-21T15:54:08.707 に答える