design-patterns - 「言わずに聞く」アプローチには説明が必要

Question

私はソフトウェア工学のパターン設計のコースを受講しています。ここでは、「結合」と「結束」に関連する設計の良い方法と悪い方法を理解しようとしています。次の画像で説明されている概念を理解できませんでした。 画像に示されているコードの例は、私にはあいまいです。そのため、「教えてはいけません」という正確な内容を明確に理解することはできません。アプローチ平均！画像から何か取り出していただけますか？はいの場合、説明してください！

ありがとう

Answer 1

SortedList最初の実装では、クラスのクライアント コードは実装に高度に結合されています。これは、学生リストが何らかの種類で実装されているという事実が漏洩しているためです。クラスが他の何百もの場所から使用されると、その内部実装を別のSortedListものに変更することは困難または不可能になります。2 番目の実装では、実装の詳細が隠され、疎結合につながります。

この原則は、デメテルの法則としてよく知られていると思います。「聞くな、言わない」という表現は聞いたことがありません。

Answer 2

tum が何であるかはわかりませんが、それで問題ありません。それは問題ではありません。重要なのは、それをどのように操作するか (どのようなメソッドがあるか) です。説明のために、tum が X 型であるとしましょう。

悪い例では、tum から SortedList を取得し、SortedList の操作を開始する必要があります。タイプ X と SortedList を密結合しているため、これは悪いことです。将来、SortedList (またはそのサブクラス) を使用したくない場合があります。配列、データベース、Web サーバーなどを使用するように X を変更すると、多くの潜在的な問題が発生します。

1. 学生を追加する場所でコードを変更する必要があります。小規模なプロジェクトの場合、それは数か所だけかもしれません。大規模なプロジェクトの場合、これは何百もの場所で使用される可能性があり、変更が頭痛の種になる可能性があります。
2. 型 X を他のユーザーが使用できるようにライブラリとして公開すると、X を使用するすべてのユーザーがコードを更新する必要があります。多くの場所でコードを更新する必要がある場合、ライブラリを使用している人は非常に動揺する可能性があります。
3. たとえば、SortedList が変更され、メソッドが追加または削除されたとします (SortedList ではそうではありませんが、作成した別のクラスであれば可能です)。学生の収容方法に関するデータ構造のみを変更する場合でも、学生を追加するすべての場所を更新する必要があります。

より良い例では、 addStudentToLecture(...) はその実装の詳細を隠しています。SortedList を使用している可能性がありますが、それ以外の可能性もあります。生徒を tum に追加したい人は、SortedList の使い方を知る必要はなく、呼び出しコードを変更せずに addStudentToLecture(...) の実装を変更できます。

Answer 3

最初の (または悪い) 例では、何をすべきかを伝えます。

学生をレクチャーに追加する方法の詳細を説明します。これにはいくつかの間違いがあります。は、そのtum内部実装の詳細を変更可能なオブジェクトとして返します。クライアントはそれを台無しにして、tumクラスの不変条件を壊す可能性があります。おそらくそれが最大の欠陥です。それとは別に、学生のリストを取得する方法の詳細と、学生を追加する方法の詳細にも依存します。これらの詳細のいずれかが変更されると、コードが壊れます...

第二に、あなたはそれを行う方法を教えていません。代わりにに作業を依頼しtumますが、作業の詳細については教えません。また、これらの実装の詳細のいずれかが変更されても、コードは問題ないことを意味します。tum実装は個別に変更できます。

お役に立てれば。