変更の観点からオブジェクト向けの設計を行う

オブジェクト向けのシステムを作成するには,機能を実現するオブジェクトの動的変化を考慮し,コード設計を行う.
すなわち,動的モデルは静的モデルを主導する.
前回の記事を振り返ってみましょう

機能のコンテキストでは、

まず連携に必要な情報を決定し、

メッセージに適合するオブジェクトを特定し、

メッセージを処理するためにコードを記述する必要がある.(凝集度、結合度およびカプセル化を考慮する必要がある)

のステータス(フィールド、メンバー変数)を決定することは最も重要ではありません.

この文章では,コードを記述する第4ステップを紹介した.
簡単な(しかし、多くのシステムのように、将来非常に複雑になる)映画の前売りシステムを通じてコンパイル時間の「クラス」を作成する際に、どのような要素を考慮するかを考えます.

映画前売りシステムの例

要求

基本情報、監督、俳優、ランニングマシンなどの「映画情報」

が実際の前売り対象となる映画『公開』

割引政策には定額割引、比例割引があり、各映画には割引政策がないか、1つしかありません.

オブジェクト向けの設計は、表示-ドメイン-永続化レイヤに適用できません.オブジェクト向け設計はdomainレイヤに限られます.

プログラミングプログラミング:トランザクションスクリプト

最初に対象者向けの勉強をした人が上の映画の前売りプログラムを作りたいなら、

最初にMovieクラスを作成し、

映画祭のカタログ、価格などの必要なすべての情報をプライベート変数に設定し、

.

getter/setterを定義します.

どこでも使えるデータを用意して、この機能はこれで、その機能はそれです...使う方法を持ってきます.しかし,データ作成後にプロセスを考えることは,オブジェクト向けの設計とは言えない.

プロセスからデータを分離したコードを作成し、データを作成してからプロセスを考慮し、条件文を使用してタイプチェックを繰り返すのは、オブジェクト向けの設計とは言えません.上記のプログラム設計の問題は何ですか.どのように改善しますか.

プログラム化-オブジェクト向けの設計を比較

デザインとは？

よくあるデザインに対する誤解は、アパートや車を建てるように、プログラムを書くときも設計を始め、設計が完了した後もコードを書くことだ.
(ソフトウェアはソフトウェアではない)
悪いサービスでなければ、サービス稼働中は再包装を継続する必要があります.
プログラマーは再構築するたびに良い設計を考慮しなければならない.

では、何がいいデザインですか。

良いデザインを一つの言葉として定義するのは「変えやすい」デザインです.
設計に関するSOLIDなどは原則として変更に関連しており,設計パターンの目的も隠し変更が多い.
面接準備時に現れる凝集度、結合度、カプセル化も変更に関する概念である.
良いデザインを行うにはいくつかの選択肢があります.
このコードは再表示するコードですか、それともコードですか.需要はどのような方向に変化していますか?
これらの問題を考慮すると,単純なプログラムコードを記述するか,インタフェースと抽象クラスを用いて複雑で柔軟なコードを記述するか,状況に応じて選択する必要がある.

変更の観点からプログラムコードを改善する

良い設計は変更しやすいコードなので、凝集度、結合度、パッケージング性(すなわち変更)の観点から、
上記のプログラムコードの問題を特定し、どのように改善するかを考慮します.

ぎょうしゅうど

凝集度は「モジュール内部の要素が相互に関連する程度」という意味である.
変更の観点から説明すると、モジュール内の要素が一緒に変更される程度になります.
モジュールがこのような理由またはそのような理由で変更を続ける場合、低凝集のコードとモジュールの変更の原因は同じであり、高凝集のコードである.
SOLIDにおけるSRP(単一責任原則)は,クラスごとに変更の理由が必要であり,凝集度に関する原則であることを意味する.
映画前売りシステムで映画価格の計算を担当する論理が割引条件、割引政策などによって絶えず変更される場合、低凝集コードであることを示す.
(実際の操作では、クラスに多くの競合やトラブルが発生する可能性があります)
割引条件、割引ポリシーが変化する場合は、実施体または修正条件、ポリシーなどの分離したクラスのみを追加することが望ましい.

けつごうど

結合度は、「1つのモジュールが別のモジュールに依存する程度」です.(これは、他のモジュールの情報量を理解していることを意味します.)
変更の観点から、「一つのモジュールが変更されたときに別のモジュールが一緒に変更された程度」です.
ISP(界面分離の原則)は変化と不変を区別する原則である.(緩い結合を保つ)
映画の前売りシステムが

int price;
...
int getPrice();
...
int calculateDiscount(int price);

priceのタイプに変更の余地がある場合、多くのメソッドの戻りタイプとパラメータタイプを変更する必要があるコードがあります.
getter/setterを乱造するのはよくない原因であり、結合度が強くなるからでもある.

カプセル化

3つの中で最も重要な概念!
パッケージは、ステータス(データ)と動作(メソッド)を組み合わせて、組み合わせて何をするかを非表示にします(=変更)!
オブジェクトだけでなく,インタフェースで隠してよく変更するタイプもカプセル化といえる.
すなわち,依存逆転原則(DIP)は常に抽象的なものに依存する.
(共通インタフェースを扱うオブジェクトはコラボレーションなので、変更の範囲が狭まります!)
上記の映画前売りシステムには、割引ポリシーのみを使用する「支払い」クラスがあると仮定します.この子にとって割引政策とは何か、
定額割引ですか、それとも比例割引ですか.知る必要はない.
したがって、割引のポリシーが常に変化する場合は、「割引ポリシー」と抽象化できます.
変化するタイプを非表示にしたほうがいいです.

だから何が良くなったの?

コード修正の恐怖を軽減できます!

正常に動作するコードを修正して配布するのは恐ろしい.特にコードが長ければ長いほど複雑になります.何を触ったのか分からないので...
プログラムコードは「割引ポリシー」「上映」「映画」などの概念を表示せず、アルゴリズムに隠されている.
その歴史を知ってこそ理解できる.
逆に,オブジェクト向けの記述が良好なコードであれば,コードの修正が必要な場合に負担を軽減するために変更を考慮することができる.
しかし,システムがどのように変更されるか分からないため,オブジェクト向けの設計を最初から行うことは困難である.
そのため、再包装を行うたびに、変更を考慮します.
これからは要求が変わるので、増えるときはストレスを感じず、イライラせずに成長のチャンスにしましょう(?)
(失敗したシステムは要求を変更しません!)

References

Joproの『対象に向かう事実と誤解』という本の講義を聞いて書いた文章だ.