私たちは、3層のアーキテクチャの状況で、可能な限り明確かつクリーンに物事を実行しようとしています。
しかし、私たちのシステムの複雑さは、先に進むための最良の方法について私たちを混乱させています。
より小さなパラメーターリストを使用して、サービスレイヤーを通過する関数のチェーンを多数使用する場合、これは何が行われているのかという点では明らかですが、これらのメソッド間で多くの機能が繰り返されているように感じます。
ただし、使用するメソッドが少なく、メソッド内の機能を変更するためのパラメーターのリストが大きい場合、これは手に負えないように見えます。
現時点での私たちの選択は、多くのロジックフローが内部にあるモノリシック関数よりも管理が簡単であると感じるため、より多くの関数を使用することです。これは明らかに、より管理しやすいコードの小さなチャンクを意味します。
DRYについてよく耳にするだけなので、メソッド内で繰り返しが行われているように感じます。しかし、それはより柔軟なようです。
どういう意味か2つの例を挙げたほうがいいと思います。次のいずれかのように聞こえます。
例を提供しなかったので、これらすべてのオプションについて簡単に説明します。
1.デザインが悪い。
3. DI\designパターンを誤って使用しています。
コードを別の方法で分割する必要があるかもしれません。DIを使用するか、使用方法を再検討する必要があります。問題を管理しやすくするために、いくつかのデザインパターンを適用する必要があるかもしれません。
2.相互作用/行動が多くのオブジェクトに広がっています。この問題に取り組むために、DCIhttp ://alexsmail.blogspot.com/2012/09/dci.html の使用を検討してください。
4.コードは実際には手続き型であり、OOではありません。 私は、手続き型コードを書くために定期的にプログラマーによってJavaで記述されたコードを見ました。メソッドの実行を微調整する多くのパラメーターがあります。解決策は、コードを再設計し、プログラマーを（再）トレーニングすることです。
ほとんどの人は、大きなメソッドシグネチャよりも小さなメソッドシグネチャを好みます。メソッドについて推論するのは簡単ですが（テストは言うまでもありません！）、DRY原則の違反を正当化するためにこれを使用するべきではありません。
小さなメソッドシグネチャを使用して、一般的な複製されたコードを内部ヘルパーメソッドに除外できない理由はありますか？
エンタープライズアプリケーションの場合、クラスとメソッドの名前、およびソリューション全体に適用されるいくつかのデザインパターンを明らかにするという善意を持った、優れた階層化アーキテクチャに勝るものはないと私は本当に信じています。このルールに従うと、単一責任の原則に違反する可能性があるため、長いメソッドを使用することは矛盾します。そのため、実際に行っていることを名前で表現することはありません。DRYの原則を使用する場合は、メソッドとクラスをクリーン、短く、明確に保ち、いくつかのデザインパターンを適用して、ソリューション全体でそれらを再利用します。
この種の「コードフィロソフィー」の詳細については、ドメイン駆動設計（Eric Evans）とClean Code（Robert C. Martin）を読むことをお勧めします。
「たくさんのメソッド」が同じ機能を果たし、変化するのはパラメーターだけだと思います。
GridBagLayout私のアプローチは、パラメータがオブジェクト内のに渡される方法と同様に、いくつかのオブジェクトを使用してデータを渡すことGridBagConstraintsです。たとえば、可能なすべての条件を含むBean "Filter"を渡す検索クエリの場合、メソッドのコードは長くは複雑ではありません（ "条件Xが指定されている->クエリにXフィルターを追加する"）。簡単に分割できます。いくつかのヘルパー関数で。
これは通常、強力に結合されたアプリケーションの症状です。AからBに移動するには、15ターンしてから、少し戻る必要があります。
結合を減らすための優れた方法は、ドメインイベントを導入することです。たとえば、ユーザーが作成されると、クラスによってサブスクライブされたときに呼び出されるドメインイベントが生成されUserCreatedます。SendWelcomeEmailNotifyAdminsOfNewUserSendIntroductionaryOffer
重要なのは、コードを強力に結合する必要がなくなったため、誰でもイベントに対応できるため、複雑さが効果的に軽減されるということです。