問題タブ [cohesion]

Web アプリケーションのルーティングと URL を定義するために yaml、xml、またはプロパティ ファイルなどの 1 つのファイルの 1 つの場所で Web アプリケーションのルーティングを行い、URL を個々のメソッドまたは関数と接続することは良い考えのように思えます。フレームワークwebapp2はそのようなもので、そのように扱うのは簡単です。正規表現を使用した URL ルーティング スキームは、yaml で定義された読みやすさのように見えます。

Struts もルーティングに xml を使用していました。ただし、Spring には、すべてのルーティングを 1 か所に集める良い方法がありません。いくつかは xml ファイルにあり、いくつかは注釈として (ハンドラーのメソッド宣言のすぐ上に書き込まれます)、いくつかは urlrewrite などのプラグインでオーバーライドできます。

Spring webapp のルーティングを 1 か所に集められないのはなぜですか? それはより良いデザインとより高い結束ではないでしょうか? また、1 つの Web アプリケーションに対して複数の Web コンテキストを使用できないことが問題になる場合もあります。サーブレットの仕様では、webapp に対して複数の webcontext を許可しておらず、それは全単射である必要があるようです。なんで？

階層化されたアーキテクチャを使用する .net/c#/Entity Framework でアプリケーションを構築しています。外部世界へのアプリケーション インターフェイスは、WCF サービス レイヤーです。この層の下に、BL、共有ライブラリ、および DAL があります。

現在、アプリケーションのビジネス ロジックをテスト可能にするために、テスト中に依存関係を注入できるように、関心の分離、疎結合、および高い結束を導入しようとしています。

以下で説明する私のアプローチで十分かどうか、またはコードをさらに分離する必要があるかどうかについて、いくつかの指針が必要です。

次のコード スニペットは、動的 linq を使用してデータベースにクエリを実行するために使用されます。実行時までクエリするテーブルまたはフィールドの名前がわからないため、動的 linq を使用する必要があります。コードは最初に json パラメーターを型オブジェクトに解析し、次にこれらのパラメーターを使用してクエリを構築し、最後にクエリが実行され、結果が返されます。

以下のテストで使用される GetData 関数を次に示します。

DAL のクエリ ヘルパー クラスとそのインターフェイスの高レベルの定義を次に示します。

上記のロジックを使用したテストを次に示します。テスト コンストラクターは、モックされた db を Context.DatabaseContext に挿入します。

私の質問に

1. このビジネス層ロジックは「十分」ですか、それとも疎結合、高い結束、およびテスト可能なコードを実現するために何ができるでしょうか?
2. コンストラクターでクエリするデータ コンテキストを挿入する必要がありますか? QueryHelper 定義は DAL にあることに注意してください。それを使用するコードはBLにあります

わかりやすくするために追加のコードを投稿する必要があるかどうかを教えてください。インターフェイス IQueryHelper で十分かどうかに最も興味があります..

カップリングと結束の意味を知っています。
次の例がありますが、保守性の問題がいくつかあるため、リファクタリングが必要です。

問題は、GLOBAL VARIABLES 以外のカップリング、結束、またはその他の保守性の問題を関連付けることができなかったことです。このグローバル変数の問題なしに次のコードをリファクタリングするにはどうすればよいですか (グローバル変数が複雑さを増し、コードの柔軟性が増すため?!)

私は以下のようにリファクタリングすることを考えていました:

これは正しく見えますか？または、これをリファクタリングする他の効率的な方法はありますか?

Java Bean の命名基準がカプセル化の実現に役立つ可能性はありますか?

カプセル化に役立つのはアクセス修飾子ではありませんか?

ベスト プラクティスでは、メソッドが 1 つのことだけを担当する必要があることが継続的に規定されています。3 つのことを行うメソッドに出会いましたが、1. ベスト プラクティスに従って分解する方法がわかりません。2.名前を付けます。また、テキストブックが常にアドバイスしているように、実生活で実際に1つのことだけを実行するメソッドがどれだけあるのだろうか?

method という名前のメソッドが 1 つ以上のことを行っていることがわかります。「メソッドは 1 つのことだけを担当する」というルールに従うことさえ可能ですか?

はいの場合、上記のアルゴリズムをどのように分解できますか?

そうでない場合、非常に多くのことを行うメソッドに名前を付けることができますか?

ユーザーが書いた 10 語を収集し、指定された順序で出力する小さな Java プログラムがあります。このままでは、プログラムは機能しますが、まとまりがありません。

私の問題は、Java/OO 言語を初めて使用するだけでなく、これを修正するための結合の概念について十分に理解していないことに起因しています。

クラス Entry はあまりにも雑然としていて、別のクラスがこのクラスの機能の一部を引き継ぐべきだと思います。

不可解なものであろうとなかろうと、ヒントや手がかりをいただければ幸いです。

元のコードは独自のコードを使用しているため、Dialogue.java に入力リーダーがないのは意図的なものです。

これらは、entry、dialog、printer の 3 つのクラスです。

Entry.java

Dialogue.java

プリンター.java

凝集度メトリックの背後にある仮定は、メソッドが同じクラスレベルの変数で機能する場合、メソッドは関連しているということです。メソッドがまったく異なる変数で機能する場合、メソッドは無関係です。まとまりのあるクラスでは、メソッドは同じ変数セットで機能します。まとまりのないクラスでは、さまざまなデータに対して機能するメソッドがいくつかあります。

メトリックでは、インスタンス変数、フィールドへのアクセスを共有するメソッドのペアの数が、そうでないペアから差し引かれます。

しかし、単純に計算を実行して値を返すメソッドはどうでしょうか? 私はそれらをたくさん持っていますが、インスタンス変数を共有していないため、それらを分離することをお勧めしますが、これは意味がありません。

彼の投稿SOLID: the next step is Functionalで、Mark Seemann は次のように述べています。

ますます小さなインターフェイスに向かって設計を進めていくと、最終的には究極の役割インターフェイスに到達します。つまり、単一のメソッドを持つインターフェイスです [...] そのように SRP と ISP を適用すると、進化する可能性が高くなります。それぞれが単一のメソッドを持つ多くのきめ細かいクラスを持つコード ベース。それは私に何度も起こりました。

私の懸念は、そのようなクラスの結束についてです。このアプローチは機能的結束を促進しますか? それらのクラスはまとまりがありませんか？コードの一貫性に悪影響はありますか?