uml - 制御クラスの用途は何ですか?

Question

クラスを境界/コントロール/エンティティ クラスとして分類する方法を理解しようとしています。私の理解は完全ではないかもしれませんが、境界クラスとエンティティ クラスを理解できます。Boundary は、ユーザーと対話するクラスです。したがって、ユーザー インターフェイスに使用されるクラスは境界クラスになります。エンティティ クラスはデータを処理します。したがって、ER図で使用するエンティティはエンティティ クラスになります。しかし、コントロール オブジェクトが使用される理由がわかりません。コントロール オブジェクトは、ドメインの機能をカプセル化するために使用されると言われています。コントロール クラスが使用されていない場合はどうなりますか。例を挙げて説明していただけますか? 境界/コントロール/エンティティではないクラスもあります。彼らは何ですか？

Answer 1

バックグラウンド

Entity/Boundary/Controlアプローチは、1992 年にIvar Jacobsonによって、ユースケース主導の Objectory 開発手法の一部として 導入されました。

当時、ジェイコブソンはエンティティ/インターフェース/コントロールという用語を使用していました。ECB に関連して見られる奇妙な円表記は、1992 年と 1994 年の彼の著書ですでに使用されていました。異議。

彼の方法の背後にあるアイデアは、非常に論理的で形式的で演繹的な分析と設計アプローチを採用することでした。それは、ユースケースでシステムの動作要件を特定することから始まります。ユース ケースの外部世界への各リンクは、ユーザー インターフェイスを完全にカプセル化するインターフェイス オブジェクトとして表されます。

各ユース ケースは、1 つまたは複数のコントロール オブジェクトとして表されます。

コントロール オブジェクト: 1 つまたは複数のユース ケースの機能をカプセル化するオブジェクト - I.Jacobson in The Object Advantage、ACM Press、1994 年

最後に、システムによって管理されるビジネス オブジェクトは、分析中にユース ケースから部分的に推測できます。

追加情報

Iconix プロセスの基礎は、 1999 年に Rosenberg と Stephen による書籍「Use Case Driven Object Modeling with UML 」の一部として紹介されました。確かに関心の分離を改善するために、いくつかの追加の堅牢性制約が導入されました。たとえば、エンティティと境界の間の直接リンクは禁止されています。コントロール オブジェクトを介してすべてをチャネリングする必要があります。

コントロール オブジェクト (実際のオブジェクトではないことが多いため、通常はコントローラーと呼ばれます) は、境界オブジェクトとエンティティ オブジェクトの間の "接着剤" として機能します - リンクされた DDJ 記事の D.Rosenberg です。

意図を明確にするための推奨事項を追加します。

境界オブジェクトとエンティティ オブジェクトはどちらも名詞であり、コントローラーは動詞です。

結論

したがって、原則として、コントロール オブジェクトはユース ケースによって提供されるビジネス ロジックを表し、一方では境界と相互作用し、他方ではエンティティと相互作用します。コントロール オブジェクトは、外部から直接呼び出す/アクセスすることはできません。

コントロール オブジェクトを避けたい場合は、システムが提供するはずの動詞/機能/ユース ケースに対応するメソッドを持つ境界オブジェクトが必要です。これは現代の ECB によるものではありませんが、Jacobson の元のアプローチによれば完全に有効です。それにもかかわらず、境界は、SOLID設計 の単一責任の原則に準拠しなくなります。

Answer 2

コントロール クラスにはビジネス ロジックが含まれます。システムの最も重要な部分です。境界はテキストが緑か青かを制御するだけで (非常に基本的に)、エンティティはデータがテキスト ファイルに保存されるかデータベースに保存されるか (これも非常に基本的に) を制御しますが、制御クラスはすべてのビジネス ロジックを実行します。境界がマウス/キーボード イベントを送信するときにエンティティで何を変更するか、逆に境界内のエンティティから何を表示するか。