問題タブ [cohesion]

デメテルの法則は、自分が直接知っている対象にのみ話しかけるべきであることを示しています。つまり、他のオブジェクトと通信するためにメソッド チェーンを実行しないでください。これを行うと、中間オブジェクトとの不適切なリンクが確立され、コードが他のコードに不適切に結合されます。

良くないね。

解決策は、あなたが知っているクラスが、関係のあるオブジェクトに責任を委任する単純なラッパーを本質的に公開することです。

それは良い。

でも、それだとクラスの結束が弱くなるらしい。もはや、それが何をするかについて正確に責任を負うだけではなく、関連するオブジェクトのインターフェースの一部を複製することによって、ある意味でコードのまとまりをなくすデリゲートも持っています。

良くないね。

それは本当に結束力を低下させるのでしょうか？それは2つの悪の小さい方ですか？

これは開発の灰色の領域の 1 つで、境界線がどこにあるかを議論できる場所ですか、それとも、どこに境界線を引くか、その決定を下すために使用できる基準を決定するための強力で原則に基づいた方法はありますか?

私は誰かに、彼のコードが複数の目的に役立つという意味で「一貫性」がないことを伝えようとしています。私はそれをうまく説明できるとは思わないので、良い参考文献や定義を探しています。

私が作っているゲームには2つのクラスがあります。

ゼロとクロスのゲームのための gui クラスとロジック クラス。GUI クラスには、JButton の配列を使用し、同じ匿名の内部クラス アクション リスナーでそれらすべてを返すメソッドがあります。

問題はこれです。ボタンをクリックすると、プレーヤー1または2の移動に応じてテキストをxまたはaoに変更したいのですが、このコードはロジッククラスにあるはずなので、何らかの形でメソッドを作成する必要がありますロジック クラスを作成し、make ボタン メソッドの anon 内部クラス アクション リスナーから呼び出します。ただし、ロジック クラスは GUI への参照を持つべきではありません。GUI にはロジック クラスへの参照があるためです。

私はこれに対するまともな解決策を考えることができません

ありがとう

保守可能なアプリケーションのための疎結合、高い結束

何度も聞く鬨の声です。コンポーネントを疎結合する方法については、多くのアドバイスがあります。

• インターフェイスに基づいて、すべての依存関係を注入します
• イベントを使用する
• 運行バスを利用する
• 等

しかし、結束力を高めるための具体的な提案を実際に聞いたことがないように感じます。誰か提供するものはありますか？

そこから回答を始めることができますが、特定の状況についてもアドバイスをお願いしたいと考えています。

私はかなり疎結合の C# Windows フォーム MVP アプリケーションを持っています。このアプリケーションは、そのコンポーネントの多くをインターフェイスに基づいており、コンストラクターを介してそれらを注入し、制御の反転コンテナー (Castle Windsor) を使用してすべてを組み立てます。

非常によく設計されていると言えます。すでにいくつかの大きな変更要求を受けており、それらを非常に簡単に処理しました。私は全体的に非常に満足していますが、特にまとまりがないというしつこい疑いを手放すことはできません. これは、唯一の開発者である私にとっては問題ではありませんが、アプリケーションを初めて使用する人にとってはかなり混乱する可能性があるのではないかと心配しています.

例を挙げましょう。このアプリケーションは、会社 A が出荷トラックに製品を充填して処理するために使用されています。これは、OutgoingTransactionInfoオブジェクト、OutgoingTransactionInfoControl (実際に情報を入力するため)、OutgoingTransactionValidator、およびOutgoingTransactionPersisterがあることを意味します。アプリを本番環境に置いて、着信トランザクションも処理するように要求されました。これらには、さまざまな情報が添付され、さまざまな検証が行われ、さまざまな方法で永続化されます。その後、B 社はトランザクション処理にもアプリケーションを使用したいと考えました。アイデアは似ていますが、情報、検証、永続性、およびおそらく他のいくつかのコンポーネントが異なります。

私のアプリケーションには優れたテスト スイートがあり、緩いので、これらの要求に非常に簡単に対応することができました。ただし、誤って無効な状態に構成するのは簡単すぎることを認識しています。たとえば、 IncomingTransactionValidatorで検証しながらOutgoingTransactionInfoオブジェクトを使用するように配線できます。違いが微妙な場合、エラーはしばらくの間検出されないことさえあります。

何か提案はありますか？そのようなリスクを軽減するためにどのような手法を使用していますか?

結合と分離とは何ですか? カップリングに関する情報は見つかりましたが、デカップリングに関する情報は見つかりませんでした。

簡単な3D CADソフトを作っています。クラス図では、多くのオブジェクトは (x,y,z) によって他のオブジェクトと区別する必要があります。「位置」と呼ばれるクラスを作成しますが、多くのクラスが位置を操作するため、結合度が高く見えるという問題があります。何か案は？

私は今、学校でプログラミングとソフトウェア設計とJavaを学んでいます。私を混乱させているクラスはソフトウェアデザインです。Wordを使用して単純なVBコードを実行し、単純なプログラムを実行しています。私のインストラクターは、現在の合計を使用することによって私がまとまりを失っていると言います。私はそれらを回避する方法を考えるのに苦労しています。これが私が話しているいくつかの擬似コードの例です（モジュールは表示されていないドライバーモジュールから呼び出されます）：

基本的DiscountPriceに、最初の2つのモジュールを結合し、次に次DeliveryPriceの2つのモジュールを結合するために使用されます。おそらく、最後のモジュールが存在する必要さえないかもしれませんが、私はこの問題を修正しました。初心者に何か助けはありますか？

あなたの仕事の90％が、非常に大規模で非常に壊れたWebサイトで問題をトリアージすることだけであると想像してください。このWebサイトが、これまでに見た中で最も緊密に結合された、最もまとまりのないPHPコードで書かれていると想像してください。これは、元の開発者を「平手打ち」リストに追加するタイプのコードです。このWebアプリケーションが、4つの非常に異なるパーツ（1つは商用、2つは「再利用」、1つはカスタム）と、1トンの仮想ダクトテープとシムで構成されていると想像してください。ウェブサイトの主要なコンポーネントが実際に正しく機能していないものに依存しているタイプのプログラミング手法が含まれていると想像してください。これらの壊れたものを修正すると、通常、他のものが壊れます。あまりにも多くの悪い経験から、「名前」を分割するなど、Webサイトの一見無害な部分を変更することを知っていると想像してみてください。フィールドを2つの別々の「最初の」フィールドと「最後の」フィールドに分割すると、サイトがひざまずき、何時間ものロールバック、マージ、およびパッチが必要になります。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。何年にもわたって顧客にコードを捨てて最初からやり直すように懇願することを想像してみてください。しかし、エンタープライズグレードの絶望と手絞りに遭遇しました。次に、ASAP / EMERGENCYチケットを取得して、他のWebサイトでは4時間かかる新機能を実装することを想像してみてください。ただし、このサイトの方がよくわかっているので、40時間見積もり、それをすぐに実行して80時間請求しますが、クライアントは問題ありません。彼らのウェブサイトでそれに慣れています。

他にも想像しておくべきことがいくつかあります。

• 現在、テストはまったくありません。
• ログインにはgoogleteenの異なるレイヤーがあります。一部の顧客は、実際にはWebサイトのさまざまなセクションに3つの異なるアカウントを持っています
• 私が「密結合」と言うとき、私はinclude/requireステートメントのループがおそらくケルトノットのようにマップされることを意味します
• 「最もまとまりがない」とは、MVCのように編成されているものもありますが、実際にはMVCではありません。場合によっては、URIAがファイルBにどのようにマップされているかを確認するだけで数時間かかることがあります。
• UIは「目立たない」と「アクセスできない」のように書かれており、当時の流行語でした

それをすべて想像すると、適度なレベルのテストカバレッジを達成しようとする価値さえありますか？または、この架空のシナリオで、与えられたものでできる限り最善を尽くし続け、クライアントがこれらの日のいずれかを書き直すことに同意し、それからあなたが書き始めることができることを願って、祈って、おそらく犠牲にする必要がありますテスト？

補遺

あなたの多くがそれを持ち出したので：私は私がこれまでに持っていたあらゆる機会に書き直しの可能性に近づきました。私が一緒に仕事をしているマーケティング担当者は、彼らのコードががらくたであることを知っています、そして彼らはそれが彼らが最初に行った「最低入札」会社のせいであることを知っています。私はおそらく、請負業者としての私の限界を超えて、彼らがこのサイトのホスピスケアを提供するために私に莫大なお金を費やしていること、そしてそれを最初から再開発することによって彼らは非常に迅速にROIを見るだろうと指摘しました。とにかく彼らが望んでいることを実際には行わないので、私はサイトをそのまま書き直すことを拒否するとも言いました。計画はBDDスタイルに書き直すことですが、すべての主要なプレーヤーを1か所に集めるのは困難であり、彼らが何を必要としているかはまだわかりません。いずれにせよ、私はそれが非常に大きなプロジェクトになることを完全に期待しています。

これまでのすべてのフィードバックに感謝します！

私はRobertMartinのCleanCodeを読んでいて、その中で彼はコードが非常にまとまりがあると述べています。

クラスには少数のインスタンス変数が必要です。クラスの各メソッドは、これらの変数の1つ以上を操作する必要があります。一般に、メソッドが操作する変数が多いほど、そのメソッドはそのクラスに対してよりまとまりがあります。各変数が各メソッドで使用されるクラスは最大限にまとまりがありますメソッドは最大限にまとまりがあります

ただし、並行コードを記述しようとする場合、競合状態を回避するために、変数のスコープを単一のメソッドに制限するように努めます。しかし、これは最もまとまりのないコードになります。

アプリケーション/クラスを設計するとき、あなたは何を好むべきですか？凝集性または並行性？