問題タブ [tell-dont-ask]

複数の戻りオブジェクトを必要とする多くのメソッドを持つJavaでプロジェクトを行っています。このために、戻りオブジェクトをカプセル化するプライベート クラスを作成し続ける必要があります。たとえば、コード内の FontResult がフォント名とフォントサイズを返すため、オブジェクトは理にかなっていますが、必要な戻り値の型ごとに新しいオブジェクトを常に作成するのは間違っていると感じ、Java の記述方法を回避しようとしているようです。これは間違っていますか、それともこのようにして問題ありませんか? 言うな、聞かないというアプローチでコードを構築する必要がありますか?

例は次のとおりです。

場合によっては、多くの設計原則が互いに矛盾することを理解しています。したがって、それらを比較検討して、どちらがより有益であるかを確認する必要があります。今までSRPの原理を意識して、それに基づいて多くの設計を行ってきましたが、この原理に従っていると、内部的には間違っていると感じることがありました. 今、私はTDAについて知るようになりました, 私の気持ちはそれでより多くのサポートを得ました:)

SRP :-オブジェクトは、他の誰でもなく、オブジェクト自身の懸念について心配する必要があります

TDA :-動作 (オブジェクトの状態のみに依存する) は、オブジェクト自体の内部に保持する必要があります。

例:- 長方形、正方形、円などのさまざまな形状があります。次に、面積を計算する必要があります。

今までの私のデザイン:-形状の状態を尋ねて面積を計算するAreaCalculatorServiceクラスがあるSRPに従っていました。この設計の背後にある理由は、形状は形状の責任ではないため、面積の計算について心配する必要はないというものでした。しかし、理想的には、新しい形状が現れた場合、AreaCalculatorService クラスを変更する必要があるかのように、各形状の下に面積計算コードを配置する必要があると考えていました (これは、拡張用に開き、変更用に閉じている原則 (OECM) に違反しています)。しかし、常にSRPを優先しました。それは間違っているようです

神話は壊れています（少なくとも私のものです）：- TDAを使用すると、オブジェクトの状態について尋ねるのではなく、形状に面積を計算するように指示する必要があるという私の感覚は正しかったようです。SRP の原則に違反しますが、OECM の原則をサポートします。設計原則が互いに矛盾することもあると述べましたが、動作がオブジェクトの状態に完全に依存している場合、動作と状態は一緒にある必要があると私は信じています。

別の例:-組織内のすべての従業員のすべての部門の給与を計算する必要があるとします。SalaryCalculatorService が部門と従業員に依存する SRP に従う必要があります。

各従業員の給与を尋ね、すべての給与を合計します。だからここで私は従業員の状態を求めていますが、それでもTDAに違反していません calcSalaryは各従業員の給与だけに依存していません.

これらの原則の両方についての私の解釈が正しいかどうか教えてください。