オブジェクトオブジェクトの概要6-7

06.情報とインタフェース

Message

対象者間で協力するためには,相互コミュニケーションの手段が必要である.情報はこの手段です.

を参照してください.オブジェクトを実装する場合、受信したメッセージはクラス実装時に明確に表示されるため、メソッドの実装中に送信されたメッセージが使用されるか、考慮されないことがよくあります.自分が送った情報を考えて、協力関係を築く.

Interface

情報、操作、標識は異なる角度からコミュニケーション過程を見る概念である.3つの言葉が交互に使われていても、ルヨンスの違いしか感じられず、おかしくはありません.
メッセージ:コラボレーションに参加する送信者と受信者の概念を含む
≪アクション|Actions|emdw≫:オブジェクトが他のオブジェクトに提供する抽象的なサービス、受信者の観点にのみ関連します.
ロゴ:操作や方法の説明、実施観点の概念.

インタフェース設計品質

最も少ないインタフェース、抽象的なインタフェースは良いインタフェースです.
良好なインタフェース,良好な協力関係を確立するために,いくつかの具体的な規則がある.

1）ディミットの法則

コラボレーションパスを制限するルール.恥ずかしいコードを書く.オブジェクトに要求せず、特定のオブジェクトにのみ連絡します.
すべてのクラスCおよびその方法Mについて、Mがメッセージを送信することができるオブジェクトは、以下のCの例でなければならない.
1)Mパラメータとして入るクラス
2)Cのインスタンス変数カテゴリ

このオブジェクト

メソッドのパラメータ

thisプロパティ

この属性セットの要素

メソッドで作成するゾーンオブジェクト

2)聞かないでやってもらいましょう

尋ねる行為そのものが情報と行為の分離を意味する.クエリーインタフェースを作成する前に、結果をエクスポートできるかどうかを考えてみましょう.

3）意図を表示する画面

インタフェースは理解しやすい意図を示さなければならない.逆に,インタフェースは情報の目的以外は徹底的に隠す.インタフェースの名前を付けるときは、意図だけを暴露したり、動作過程を暴露したりしないでください.開発は名前のように...

4）分離命令照会

プロシージャ:ステータス変更(State Change)が生成されますが、値は返されません.Commandとも呼ばれます.
関数:負の値を持たない戻り値を返します.Queryとも呼ばれます.
プロセスと関数を区別することが重要です.一つの方法で二つの役を同時に演じさせてはいけない.
関数にはSide Effectの特性がないため,最近注目されている.関数式プログラミング、反応式プログラミングは関数の参照投影性に基づいている.

原則に例外がある。

ディミットの法則はDotを強制するルールではない。

IntStream.of(1, 15, 20, 3, 9).filter(x -> x > 10).distinct().count();

上のコードは、同じオブジェクトを返し続け、そのオブジェクトのインタフェースのみを使用します.ディミット法則が要求する範囲のオブジェクトとしか通信しないからといって,ルール違反ではない.列車衝突形態コード自体は問題ではありません.

質問のコードはいつもよくありませんか?

複数のオブジェクトを含むオブジェクトがこれらのオブジェクトの動作を調整する場合、クエリインタフェースがない場合、結合度が増加します.Movieは条件をConditionに尋ね、PolicyとConditionを結合するよりもPolicyを選択したほうがよい.

責任

最終的に責任が正しく割り当てられたかどうかに帰結する.原則として例外があるので、設計を助ける道具として盲目的に信じてはいけない.したがって、上記のルールを使用していますが、このオブジェクトがこの責任を負っているかどうか、ロールとしてバンドルできないかどうかを常に考慮します.
契約どおりに設計する
インタフェースでは、メッセージの実行条件を定義できません.したがって,コードから見ると,メッセージ呼び出しは送信者が行い,検証は受信者が行う.それを克服するために、契約の設計概念に基づいて誕生した.

07.分解対象

人間は複雑な問題を分解したり抽象化したりして、短期記憶の小容量を克服した.プログラミングの世界では、複雑さを克服する方法も同じです.

きのうぶんかい

最大の問題は抽象的な主論理が具体的な関数に依存することである.これにより生じた問題は以下の通りである.
1.主関数を頻繁に再設計する
2.ビジネスロジックとUIの強力な結合
3.変更があれば、Mainを修復する必要があります.
また、新型インフルエンザのアイテムは1つのMainで構成されていないことも機能分解を困難にしている.機能分解は,すでに形成された論理を整理する際に,あるものを創造する際よりも有効である.(アルゴリズムの問題を解く)

モジュール

モジュールは、変更が発生したときに変更の波及を遮断する方法を提供します.モジュール内部はデータ値とこれらの値を使用する方法で構成され,外部には自分が暴露したい情報のみが表示される.
長所
グローバル変数汚染防止
モジュール内部の変更は、モジュール内部のみです.
げんかいてん
データのプロパティを定義するのではなく、値を持つため、インスタンスを作成できません.
変更を管理するために作成されたため、抽象化の観点から明確な限界がある.

Abstract Data Type

タイプ:変数に格納可能なコンテンツ+変数の演算に使用可能なタイプ数
これは,従来の機能分解方式の限界を認識して出現したデータ抽象概念である.

Object

抽象データ型とオブジェクト
オブジェクト:多形性、データ中心のプロセス抽象、タイプ基準の製品バンドルをサポートします.
抽象データ型:多形性はサポートされず、データ中心抽象型、製品標準バンドル型です.
抽象化は、ある部分を隠し、ある部分を残すプロセスであり、抽象データ型とオブジェクトの表面は同じタイプに見えるが、表示される情報は異なるようだ.Objectのタイプは、より多くのデータ関連情報を隠し、より多くの行動関連情報を暴露しているようです.
多形支援の有無が分かれば問題ない.