「マネージャー」クラスの使用を減らす方法に関するヒント/アドバイスは？

プログラムの設計に「マネージャー」クラスが多すぎるとコードの匂いがして、不要な複雑なレイヤーが追加されると聞きます。私にとって、人々が意味のあるコンテキストからオブジェクトを操作および制御するためにマネージャークラスを使用したいのは理にかなっていますが、ソリューションをそれらなしで機能させる方法を理解することは混乱する可能性があります。

マネージャークラスを可能な限り避けるべきですか？また、これらのマネージャーを削除できる一般的な/一般的なケースの代替回避策を実装する方法について、どの記事/論文を読むべきですか？

これがコードのにおいである理由はおそらく2つあります。1つの理由は、ドメインオブジェクトを持たず、コントローラーまたはマネージャークラスによる操作のためのデータを保存するだけの値オブジェクトを持っていることを意味する場合があるためです。これは実際にはかなり一般的であり、OO言語での手続き型プログラミングに相当します。「たくさんのマネージャー」は、実際に何かをカプセル化するために、状態ロジック、検証、およびその他の直接的な懸念をドメインオブジェクトに統合する必要があることを示すヒントかもしれません。もちろん、ゲッター/セッター以外のメソッドがないという事実など、より大きなヒントがあります。

コードの匂いがするもう1つの理由は、ドメインオブジェクトが実際には相互に非常にうまく関連していないことを意味する可能性があることです。たとえば、Transactionという名前が付けられている以外はTransactionクラスについて何も知らないAccountクラスがあり、それらが複数存在する可能性がある場合、非常に活気のあるビジネスドメインの実装は実際にはありません。たとえば、SavingsAccountは、accountStatusが閉じている場合、DebitTransactionを受け入れられないことを知っているはずです。実装の多くは、これをマネージャーに任せます。

多くの「マネージャー」クラスを持つことは、多くの場合、ドメインロジックがドメインモデルから引き上げられ、代わりに多かれ少なかれトランザクションスクリプトに相当するマネージャークラスに配置される、貧弱なドメインモデルのシンプトンです。ここでの危険性は、基本的に手続き型プログラミングに戻ることです-プロジェクトによってはそれ自体が良いこともそうでないこともありますが、それが考慮または意図されていなかったという事実は「コードの匂い」です。

「情報エキスパート」の原則に従って、論理演算は、必要なデータのできるだけ近くに配置する必要があります。これは、ドメインロジックをドメインモデルに戻すことを意味するため、トランザクションスクリプトがドメインモデルの状態を外部から変更するのではなく、これらの論理操作がドメインモデルの状態に目に見える影響を与えます。

マネージャクラスの最大の問題は、クラスが何をすべきかについてのあいまいな考えしか表していないことです。何かをマネージャーと呼ぶと、管理しているものに関係するあらゆることや可能なすべてのことができます。状況によっては大丈夫かもしれませんが、ほとんどすべての場合、それはあなたが望んでいるものではありません。誰かにクラス名を見てもらい、クラスが何をするのかだけでなく何をしないのかについての素晴らしいアイデアを持っているようにしたいのです。

マネージャークラスのもう1つの問題は、機能の配置先を決定することが非常に困難になることです。マネージャークラスが多数ある場合、マネージャークラス間で機能の重複が頻繁に発生します。次に、どのクラスがその重複する機能を実装する必要があるか、そしてもちろん他の誰かが異なる方法で選択することになるものを把握する必要があります。したがって、彼らが機能を探して、期待する場所でそれを見ない場合、彼らは先に進み、他の実装の存在を知らないので、それが属すると思う場所で再実装します。言い換えれば、マネージャークラスは、理解しにくく、頻繁に複雑な設計につながります。