接着剤や管理のクラスが多すぎるのはいつですか？

デザイン内の他のクラスを管理する集中型クラスを作成する傾向があります。それ自体はすべて保存されませんが、ほとんどのデータ要求は最初に「マネージャー」に送信されます。この質問への答えを見ていると、「神のオブジェクト」という言葉に気づきました。ウィキペディアは、それを当然のことながらアンチパターンとしてリストしています。

データとメッセージを場所から場所へと渡す正当な接着剤クラスまたはモジュールと、やり過ぎているクラスとの間の境界はどこにありますか？

「クラスはあなたの頭よりも大きくてはいけない」のようなことを言う人はたくさんいます。

しかし、私はこのテーマについて、本当に素晴らしい世界クラスのプログラマーとのディスカッションに参加しました。私はそれをNaked Objectsの人たちと話しました。私たちが知る限りでは、これは時々起こり、それを回避する方法はあまりありません。

ただし、通常、これが発生する1つのクラスは、ドメインの基本的な要素を表すドメインオブジェクトです-銀行口座、小売販売など。他のクラスでも発生する場合は、おそらくそのクラスの責任を検討したい。ここに私のヒントがあります：

• それが「マネージャー」、「ヘルパー」、または「サービス」と呼ばれている場合、それが大きすぎる可能性があります。クラスの責任を実際に理解すると、他の責任を委任するのが簡単になります。
• それが「コントローラー」と呼ばれる場合、それは他のクラスの束の間の相互作用を制御する責任があるはずです...
• それは、異なる物理ノード間でデータとメッセージを渡すだ場合、どちらかは直列化された形式に特定のメッセージを変換するに対処する必要があり、またはそれは、移動機構を扱います。たとえば、銀行取引をXMLに変換するクラスと、そのXMLをHTTP経由で送信する別のクラスがあるとします。
• アプリケーションの異なるモジュール間でイベントを渡す場合は、イベントが発生したときにリスナーに通知する必要があります。

経験則として、大きすぎる場合は、責任を別のクラスに委任できるかどうかを確認します。委任できない場合は、おそらく問題ありません。