AメソッドM1を持つクラスを想定M2し、他のクラスとの結合度が低い

a）クラス内の個々Aのメソッドが、同じクラス内の他のメソッドと緊密に結合されていないことも確認する必要がありますか？したがって、でコードを変更しA.M1ても、でコードを変更する必要がないことを確認する必要がありA.M2ますか？

b）単一のタスクではなく、A.M1密接に関連する2つのタスクT1とT2を実行している場合、の変更には？の変更も必要になる可能性があるため、 T1とT2は緊密に結合されていると思います。T1T2

ありがとうございました

これが私の状況です。いくつかのパラメーターを選択するための複数のコンボボックスを備えたフォームフォームを備えた単一のビュー (ビューVと呼びましょう) があります。

これらのコンボ ボックスのオプションを AJAX 呼び出しで動的に読み込みたい (コンボ ボックスで 1 つの項目を選択すると、他の項目にデータが読み込まれます)

各コンボボックスは、フレームワーク上の異なるコントローラー (データを取得するために異なるモデルを呼び出す) に対して AJAX 要求を行います。これらのコントローラーをC1、C2、C3、モデルをM1、M2、M3と呼びましょう。

C1、C2、およびC3のこれらの AJAX スクリプトは、将来の他のビューで使用される可能性が非常に高いです

しかし、これが正しい方法であるかどうかは疑問です。これらの AJAX スクリプトはどこに置くのですか? 各コントローラーまたは個別のコントローラー (おそらく FormAPI などと呼ばれます)

各コントローラーに 1 つの ajax スクリプトを配置すると、V がC1、C2、およびC3と結合されますが、3 つの要求に対して 1 つのコントローラーを作成すると、ビュー V と 1 つのコントローラーのみが結合されます。また、私の観点からは、そのようなコントローラーは非常にまとまりがあります。

ただし、 C1、C2、およびC3には、「 M1、M2、およびM3のリストを取得する」というタイプのリクエストを受け取るロジックが既にあるため、コードを DRY に保持していない可能性があります。これを JSON としてレンダリングしてビューVに返すことができます。

C1、C2、C3、... CNへのリクエストを必要とする別のビューV2がある場合、将来どうなりますか? すぐに私のコードは「スパゲッティ結合」になると思います

どう思いますか？

別の質問: 項目の配列とリストを取得するには、M1、M2、M3 にロジックが必要ですか? たとえば、M1 に M2 の複数のインスタンスがある場合、メソッド M1->getM2asArray() を作成するのは正しいですか?

別の開発者によって作成されたクラス (ソースを持っていない) に基づいて構築されたアプリケーションを開発しています。

上記のクラスのすべての機能を使用したいだけでなく、追加機能で拡張したいと考えています。通常、これを実現するには、インターフェイス ( MyInterface ) を定義し、MyInterfaceを実装しながら、自分自身 ( MyClass ) から外部クラス ( TheirClass ) を拡張します。

この問題は、次の事実によって複雑になります。

1. MyClassに機能を追加する新しいクラス ( MyNewClass ) を作成したいと考えていますが、自分のコードをTheirClassに依存させたくありません。
2. クラスをTheirOtherClassのメソッドのパラメーターとして使用できるようにしたいと考えています。

これに対抗するために、コードをリファクタリングして、代わりに継承よりも構成を使用し、TheirClassInterfaceを実装しました。これは機能しますが、多くのメソッドを実装し、それらをtheirClassObjectに委譲する必要があります(実際には、 TheirClassInterfaceには非常に多数のメソッドが含まれています)。

私の質問は、この場合に私のアプローチが適切かどうか、および私のコードが仕事を成し遂げるために過度の量の委任を使用しているように見えるので、改善できるかどうかです。

誰でもこれについて与えることができるガイダンスに感謝します。

ダニー

最初に言っておきますが、私は OO パターン、プラクティス、クリーン コードなどの経験があまりありません。実際、これらすべてのテクニックを学んでいます。

最も疎結合の方法は、新しいオブジェクトの構築またはメソッドの実行にプリミティブ型を使用することですが、それは実用的ではないと思いますが、これは正しいですか? エラーが発生しやすくなるからです。単純に存在しない Id を表す整数を引き渡すことができます。オブジェクトを使用する場合、有効なデータがあることを実際に知っています。そうしないと、オブジェクトが作成されないか (例外)、チェックする必要がある無効な状態になります。

この記事では、これに具象オブジェクトを使用するのは悪であると述べています。代わりに、そのインターフェイスを引き渡す必要があります (ご存知のように)。具象型 (インターフェイスではない) を変更すると、依存型が「故障」します。それはすべての場合にそうですか？これは、閉じた単一プロジェクト環境にも当てはまりますか? インターフェイスが一度作成されると、変更できず、再度変更/リファクタリングできない場合にのみ理解できます。

JFrame を拡張するメイン クラス (Main.java) があります。

メイン クラスには、2 つのパネルを含む左側のパネルが含まれています。最初のもの (Component) には多くの TabelPanel が含まれ、2 つ目は Property という名前です。

ボタンを含む中央パネル (デザイン) と下部パネルがあります。デザイン パネルには jtree が含まれています。

コンポーネント パネルから要素を取得し、jtree にドラッグ アンド ドロップします。jtree で要素を選択すると、プロパティ パネルに情報を表示する必要があります。

下部 (下部パネル) をクリックすると、jtree パネルに反復する必要があります。

どこでも参照する代わりに、それを回避する最善の方法は何ですか?

キューメッセージを受信し、他のいくつかのクラスを使用して何らかの作業を行うこのメインクラスがあります。これらの他のすべてのクラスは、いくつかの下位クラス自体を使用し、最終的にデータはデータベースに書き込まれるか、wcf サービスに送信されます。

下位クラスの結果に基づいて、メインクラスは、キューメッセージを削除するか、キューに再度配置するか、デッドレターキューに送信するかを決定する必要があります。

たとえば、データベースに到達できない場合は、後で再試行するためにキューメッセージをキューに入れることができます。しかし、wdcf サービスが一部のデータを受け入れないことを返した場合、メッセージをデッドレターキューに送信する必要があります。

このシナリオを実装するには、いくつかの方法があります。

1. 例外をスローし、メイン クラスでのみ処理します。
2. 例外をスローしますが、呼び出し元の各クラスで例外をキャッチします。そして、新しい例外を再スローします
3. エラー/成功状態を示す結果オブジェクトを返します

これらは、シナリオに関する私の考えです。

1. 最下位クラスの 1 つが例外をスローし、メインクラスがそれを処理する必要がある場合、メインクラスを最下位クラスに結合します。最下位のクラスの 1 つが例外を変更することを決定した場合、メインクラスの例外処理を変更する必要があります。

2. C# で呼び出されたクラスからスローされる例外を上位クラスに知らせる良い方法はありません。

3. これは私が好むものです。呼び出されたすべてのメソッドは、成功または失敗を示す列挙型と失敗のタイプを含む結果オブジェクトを返すことができます。

したがって、私の好みの方法はオプション 3 ですが、それがアーキテクチャ的に受け入れられるかどうかはわかりません。または何か良い方法があれば。

コード

コードは次のようになります (簡略化された形式)。

QueueHandler

DeliveryOrderHandler

DeliverDocumentToExternalSystem

ご覧のとおり、うまくいかないことがたくさんあります。データベース接続の失敗、wcf サービス呼び出しの失敗、ファイルが存在しないなど。

私はこれを防ぐことができると思っていました：

QueueHandler

私は単体テストに本当に慣れていないので、調査に膨大な時間を費やしましたが、自分の場合に適切な方法を見つけることができません。

私のコード ベースは巨大で (約 3 年間の作業)、非常に結合されており、残念ながらテストが難しく、ユニット テストが行​​われたことはありません。

たとえば、コレクション クラスProductCollection、より具体的にはそのクラスをテストしようとするbool MoveElementAtIndex(Product productToMove, int newIndex)と、次の問題が発生します。

• まず、これを初期化する必要がありますnew ProductCollection()
• コンストラクターは、別の手作りのクラスを初期化します: new KeyedList<ID, Product>. 私はテストしていないので、これはこのコンストラクター内で呼び出されるべきではないと思いますKeyedList。
• 次に、これに 3 つの製品を追加しようとしていProductCollectionます。
• 次に、これら 3 を最初に作成しますnew Product()。
• しかし、Productクラスのコンストラクターはいくつかのことを行います
• 新しく作成された製品の一意の ID を計算します: this.ID = IDUtils.ComputeNewIDBasedOnTheMoonPhase(). 私の範囲ではないので、これもテストすべきではないと思います。このレベルの深さでそのような呼び出しを回避するにはどうすればよいですか?
• 同じ Product コンストラクターが、この製品にいくつかの既定のプロパティを割り当てます: this.Properties = new ProductProperties(folderPathToDefaultProperties). FieldCollection.MoveElementAtIndexこれは私の単純なテストから呼び出されるべきではありませんよね?
• ようやく製品オブジェクトを手に入れ、コレクションに追加しようとしているとしましょう。
• ただし、ProductCollection.Add(MyProduct)基礎にKeyedList既に製品が含まれているかどうかを確認します。これは、私のテストとは関係なく、避けるべきビジネス ロジックでもあります。問題はどのようにですか？
• また、このAddメソッドでは、いくつかのイベントが発生し、いくつかのこと (たとえば、新しい製品がコレクションに追加されたこと) についてシステムに通知されます。これらもまったく解雇されるべきではないと思います。
• そして最後に、製品を追加したら、必要な SUT を呼び出します: move elements メソッドです。
• しかし、このメソッドには、私のテストの範囲外になる可能性のあるロジックもあります。基になるKeyedListフィールドに実際にこれらのフィールドが含まれていることを確認し、その移動ロジックに対して を呼び出しKeyedList.Remove()、のようなイベントを発生させます。KeyedList.Insert()CollectionModified

この単体テストを適切に行う方法、基になるオブジェクトが呼び出されないようにする方法を説明していただければ幸いです。

Microsoft の Moles フレームワーク (VS2010) について考えています。これは絶対に選択肢ではないため、すべてをリファクタリングする必要がないという印象があるからです。しかし、すでに試してみても、まだ適切な使用方法が見つかりません。

また、この具体的な例は私の状況で多くの人を助けるという印象を持っています.

何かご意見は？

これまでの私の知識では、カップリングは 2 つ以上のクラスが「相互接続」されている程度に関連していると考えていました。つまり、クラスが他のクラスのメソッドまたは変数をどの程度使用するかということです。適切に設計されたソフトウェア システムにおける私たちの目標は、もちろん結合を低く (緩く) 保つことです。

私は現在本を読んでいますが、疎結合の目的はシステムを設計することによって達成され、すべてのクラスが他のクラスの API (パブリックメソッド) のみを使用し、インスタンス変数を直接使用しないように明示的に述べている本を読んでいます。したがって、インスタンス変数はプライベートでなければなりません。それがポイントである場合、疎結合と強力なカプセル化の違いは何ですか? 私に関する限り、後者はカプセル化を指します。オブジェクト指向ソフトウェア開発の上記の概念に関して実際に正しいのはどれですか?

このスレッドのように、Java クラスのインターフェイスを使用するというアドバイスについて少し混乱しています: Java クラスのインターフェイスを優先する必要があるのはなぜですか?

インターフェイスを使用したい理由は理解できます。後で何かが変更された場合、クリーンアップするコードが少なくて済みます。

しかし、Interface を使用すると、そもそもその特定のクラスを選択したパフォーマンス上の理由を利用できなくなる場合はありませんか?

たとえば、TreeMap がある場合、最大でも O(logn) で任意の要素を見つけることができるはずだと思います。そのため、higherEntry()、lowerEntry()、lastEntry() など、私が利用できる優れたメソッドがあります。

代わりにこの TreeMap を Map として参照すると、O(n) のリストを一度に 1 つの要素を繰り返し処理して、そのエントリを見つける必要があると思います。

私は Java を初めて使用するので、ここで何か不足している場合はお知らせください。

「より大きな」アプリケーションを作成していて、クラスで特定のエラーをログに記録したいとしましょう。現在、ほぼすべてのクラスが Logger にアクセスする必要があります。

1つの簡単な解決策は次のとおりです（PHPですが、それは問題ではありません）：

このアプローチの問題は、Logger を使用するすべてのクラスがそれに依存するようになり、Logger なしで他のプロジェクトで同じクラスを単純に使用できないことです。しっかりと結合されています。また、 の実装を変更せずに、メッセージがログに記録される方法を変更することはできませんSomeClass。

上記のアプローチの「少し」のアップグレードは次のようになります。

SomeClassは単純に に依存し、LoggerFactoryそれに密結合しているため、これで問題が実際に解決されるわけではありません。これの良いところは、クラスLoggerFactoryのさまざまなインスタンスを返すことができるようになったことです。Loggerしたがって、メッセージが記録される方法を変更したい場合、 の実装を変更する必要はありませんSomeClass。

別のアプローチは、依存性注入を使用することです。

SomeClass現在、これは特定のクラスに結合されていません。Loggerインターフェイスを実装するクラスが必要なだけです。Loggerしかし、これに関する問題は、オブジェクトを作成するたびにインスタンスをコンストラクターに渡す必要があることです。

これに関するもう 1 つの問題は、Logger が実際にはandのPositionようなクラスの一部ではないことです。それは単なるユーティリティです。$x$y

そのような状況にどのように対処するのが最善ですか? この場合、カップリングと結束の間の最適な妥協点は何でしょうか?