問題タブ [grasp]

学校で GRASP パターンを学んでいますが、Creator パターンについて質問があります。

Computer、UserRespository、およびUserの 3 つのクラスがあるとします。

GRASP Creator パターンの規則の 1 つは、オブジェクトを作成する責任を、それらのオブジェクトを含むクラスに割り当てるように指示します。このガイドラインに従うことで、UserRepository が User の作成者になる必要があります。

したがって、Computer がユーザーを作成する場合は、UserRespository に問い合わせます。

これにより、 ComputerがUserから効果的に分離されます。本当に？

明らかに、Computerには User への言及はありませんが、Computer は依然として User の作成と強く結びついていると思います。なんで？createUserメソッドは、作成をうまく隠していません。ユーザーがコンストラクターを変更する場合、 createUserメソッドを変更して、それらの変更と、メソッドを使用するすべてのクライアントを反映する必要があります。

このパターンを使用する利点は何ですか？

複数の状態になる可能性のあるドメインモデルがあり、これらの状態が特定の範囲外になると、ドメインは自動的に反応するはずです。

たとえば、私は測定値を持つ複数のものでできている車を持っています

エンジン-タコメーターと温度

燃料タンク-容量

エンジンとタンクを監視するCarStateControllerを使用するのが妥当です。これらの状態が範囲外になる場合、つまりエンジン温度が範囲を超える場合は、エンジンファンをオンにします。

UIはありません（ダッシュボードにライトが表示されると主張できますが、この場合は表示されません）。これはGRASPコントローラーパターンの有効な使用法ですか？そうでない場合、このCarStateControllerは何と呼ばれますか？

または、私は完全に要点を見逃しましたか？これは状態パターンである必要がありますか？

.net でファサード コントローラー パターンを使用する。ドメインオブジェクト（販売、登録、スケジュール、車）で発生するすべてのイベントについて、コントローラー（ユースケースコントローラー）によってサブスクライブする必要があり、コントローラーが順番に持っているため、効率的ではないようです同じイベントを複製してプレゼンテーションで使用できるようにし、プレゼンテーションでユーザーに表示できるようにします。これは理にかなっていますか？コメントしてください！

Graspのコントローラーパターンの背後にある考え方は何ですか？

私の現在の解釈では、いくつかのクラスを使用する必要があるものを達成したいが、それらのクラスのいずれもそれを行うために必要な情報にアクセスできない、またはアクセスできない場合があるため、必要なすべてのクラス（これは、情報の専門家である可能性があります）。

これは、Graspのコントローラーが何であるかについての正しい見方ですか？

一般に、コントローラーをグーグルまたはSOする場合、理解できないトピックであるMVC（およびその他）に関する結果が得られるだけなので、ASP.NETのMVCなどを知っているとは思わない回答が必要です。 （（

ありがとう

GOFパターンとGRASPパターンの違いについて本当に混乱していますか？どちらもオブジェクト指向プラクティスの改善に貢献します

私は Java を使用してタスク マネージャー プログラムを作成し、現時点で単一の UI 実装を作成しました。現在、プログラムには 3 つのレイヤーがあります。ユース ケース コントローラーを介してドメイン層と対話するプレゼンテーション層、および最後に永続化に使用される技術サービス層。この時点で、タスクの追加、タスクのステータスの編集など、ユーザーが実行できるアクションがいくつかあります。このスキームでのロガーの目的は、ユーザーが実行したすべてのアクションを追跡することです。そのため、ロガーを呼び出してコマンドを書き込むことができる場所がいくつかあります。これはひどい設計上の決定になるため、プレゼンテーション レイヤーでのログ記録は行いません。そのため、コマンド インターフェイス (元に戻す/やり直し機能を実装する目的ですべてのコマンドの実行を処理するために実装された) のコントローラーが残されます。 )、

コントローラーは、UI レイヤーとドメイン間の接点として機能するため、これには比較的適切なオプションだと思います。したがって、すべての重要なコマンドは最終的にコントローラーを通過し、すべての重要なメソッドがログに記録されていることを簡単に確認できます。 . コントローラーでこれを実行しない理由は、凝集度が低下し、カップリングが増加し、コントローラーが肥大化する可能性があるためです。

具体的なコマンドも、ログに必要なすべての情報を持っているため、別の潜在的な場所です。これにより、コマンドの凝集性が低下し、結合が増加します。また、ドメイン オブジェクトに対してアクションを実行するためにコマンド インターフェイスを使用しないと、ログが失われます。

最後に、これにより、ロガーを下位レベルのドメイン オブジェクト メソッドに実装することになります。プログラムが使用されていて、必要なすべての情報が利用可能な場合、ログは常に発生するため、これは適切な候補です。唯一の欠点は、ロガー コマンドが下位レベルのドメイン オブジェクトにまばらに分散され、正しいメソッドがすべてログに記録されていることを確認することが難しくなることです。

この種の決定について議論を進めたいと思います。皆様のコメントをお待ちしております。

デザイナーとして、私はパワーとシンプルさのバランスに対応するインターフェースを提供するのが好きです。たとえば、LINQの設計者は、ドット表記とクエリ表記の両方を提供しているため、この原則に従っていると思います。前者はより強力ですが、後者は読みやすく、理解しやすいです。LINQの私の評価に同意できない場合は、とにかく私のポイントを確認してみてください。LINQは単なる例であり、私の投稿はLINQに関するものではありません。

私はこの原理を「ダイヤル可能な力」と呼んでいます。しかし、私は他の人がそれを何と呼んでいるのか知りたいです。確かに「KISS」は一般的な用語だと言う人もいます。しかし、私はKISSをスーパーセット、つまり「消費主義」の実践と見なしています。再び私の例としてLINQを使用すると、私の見解では、ドット表記よりもクエリ表記を常に使用しようとするプログラマーのチームがKISSを実践しています。したがって、LINQの設計者は「ダイヤル可能な電力」を実践しましたが、LINQの消費者はKISSを実践しました。二人は一緒に美しい音楽を作ります。

編集別の例を挙げましょう。2つの使用を可能にする2つの署名を持つロギングツールを想像してみてください。

2つの署名の目的は、次のニーズを満たすことです。

消費者はシンプルなインターフェイスまたは強力なインターフェイスを選択できるため、これらの過負荷があることは「ダイヤル可能な電力」を表します。KISSを愛する消費者は、ほとんどの場合、より単純な署名を使用し、電力が必要なときに「忙しい」外観の署名を許可します。強力な署名を使用すると、コードのパフォーマンスが重要であることがリーダーに通知されるため、これは自己文書化にも役立ちます。ロガーに強力な署名しかない場合、「ダイヤル可能なパワー」はありません。

つまり、これは完全に一周します。自分の「ダイヤル可能なパワー」のコインがまだ存在しない場合は、それを維持できてうれしいですが、このプラクティスの明確な指定が欠けていると思わずにはいられません。

ps関連しているが、「ダイヤル可能な電力」と同じではない別の例は、Scott Meyerの原則であり、「インターフェイスを正しく使いやすく、誤って使いにくいようにする」というものです。

サービス/アプリケーション レイヤーは、Larman が GRASP コントローラーとして説明しているのと同じものであり、GUI レイヤーを超えてドメイン レイヤーにデリゲートする最初のオブジェクトであり、別の GUI から再利用できるはずだと思います。

サービス (Evans) 層はアプリケーション (Fowler) 層と同じです。これは、Fowler 自身が「Anemic Domain Model」に関する「bliki」でそう言っているためです: http://martinfowler.com/bliki/AnemicDomainModel.html

引用: 「アプリケーション層 [サービス層の彼の名前]: ソフトウェアが実行することになっているジョブを定義し、表現力のあるドメイン オブジェクトに問題を解決するように指示します。この層が担当するタスクは、ビジネスにとって意味があるか、相互作用に必要です。他のシステムのアプリケーション層. この層は薄く保たれています. ビジネスルールや知識は含まれていません. タスクを調整し、次の層のドメインオブジェクトのコラボレーションに作業を委任するだけです. ビジネス状況を反映した状態を持たない.ただし、ユーザーまたはプログラムのタスクの進行状況を反映する状態を持つことができます。」

ここで、上記の説明を検討し (ユース ケースからサービス層メソッドを特定することに関して、ファウラーの PEAA ブックも参照してください)、サービス層が「ユーザー インターフェイス」の後の最初の層であることを示すファウラーのサービス層の説明の図も検討してください。この URL: http://martinfowler.com/eaaCatalog/serviceLayer.html

ここで、上記のサービス/アプリケーション層の説明を GRASP コントローラーに関する Larman の言葉の一部と比較してください (彼のベストセラー OOAD 書籍「Aplying UML and patterns」の第 3 版、302 ～ 306 歳):「...最初のオブジェクトシステム操作を受け取り、調整 (「制御」) する UI レイヤーを超えて..." "... システム イベントが発生するユース ケース シナリオを表す..." "... 通常、コントローラーは他のオブジェクトは、実行する必要がある作業です。アクティビティを調整または制御します。それ自体は多くの作業を行いません...."

Larman の GRASP Controller レイヤーは、Evans/Fowler の Application/Service レイヤーと同じだと思います。他の人は同意しませんか？次に、これらの概念の大きな違いと、Service/Application クラスの代わりに Controller クラスの例を説明してください。

モデル ドメイン オブジェクトの作成は、他のサービス/アプリケーション レイヤーではなく、コントローラーの責任であると言う人もいるため、私の質問が生まれました。しかし、サービス層クラスの例とコントローラークラスの違いを教えていただけますか?

GRASP Creator は Dependency Injection と完全に矛盾していますか?

そうでない場合は、その理由を説明してください。

宿題があり、GRASP に従ってどちらのアプローチが優れているかを評価する必要があります。

私の質問の一部に答えるこのリンクを見つけました: C++ にヘッダー ファイルと .cpp ファイルがあるのはなぜですか?

ただし、私が知りたいのは、すべてが結合ファイルで定義されているため、Java よりも拡張性とコードの再利用の点で C++ の作業方法がどれだけ優れているかということです。

助けてくれてありがとう ！

編集：これが議論ではないことを確認するために、JAVAがCのように機能せず、クラス定義とクラス実装の分離を促進する理由を知りたい. その働き方や進め方に利点はありますか？

この質問はhttps://softwareengineering.stackexchange.com/questions/118574/does-java-promote-a-separation-between-class-definitions-and-implementations-asに移動されました