マネージャクラスは、悪いアーキテクチャの兆候ですか？

最近、デザインにマネージャークラスをたくさん持つのは悪いことだと思い始めました。このアイデアは説得力のある議論をするには十分に成熟していませんが、いくつかの一般的なポイントがあります：

• 「マネージャー」に大きく依存しているシステムを理解することは、私にとってはるかに難しいことがわかりました。これは、実際のプログラムコンポーネントに加えて、マネージャの使用方法と理由を理解する必要があるためです。

• マネージャーは、多くの場合、プログラマーがプログラムJust Work ^TMを作成する方法を見つけることができず、マネージャークラスに依存してすべてが正常に動作する必要がある場合など、設計の問題を軽減するために使用されるようです。

もちろん、飼い葉sは良いことができます。明らかな例は、EventManager私のお気に入りの構造の1つです。：P私のポイントは、マネージャーが多くの時間を使いすぎているように見えることであり、プログラムアーキテクチャの問題を隠す以外の正当な理由はありません。

マネージャークラスは本当に悪いアーキテクチャの兆候ですか？

マネージャークラスは、いくつかの理由で、悪いアーキテクチャの兆候である可能性があります。

• 意味のない識別子

  名前FooManagerは、クラスが実際に何をするかについて何も言いませんが、それは何らかの形でFooインスタンスを含むことを除いて。クラスにもっと意味のある名前を付けると、その真の目的が明らかになり、リファクタリングにつながる可能性があります。

• 分数責任

  単一の責任原則に従って、各コードユニットは1つの目的を果たす必要があります。マネージャーを使用すると、その責任を人為的に分割できます。

  インスタンスのResourceManager有効期間とResourceインスタンスへのアクセスを調整するを検討してください。アプリケーションには、インスタンスをResourceManager取得するための単一のものがありResourceます。この場合、ResourceManagerインスタンスの機能をResourceクラス内の静的メソッドで提供できない本当の理由はありません。

• 非構造化抽象化

  多くの場合、マネージャーは、管理するオブジェクトの根本的な問題を抽象化するために導入されます。これが、管理者が不十分に設計されたシステムのバンドエイドとして悪用するのに役立つ理由です。抽象化は複雑なシステムを単純化する良い方法ですが、「マネージャー」という名前は、それが表す抽象化の構造に関する手がかりを提供しません。それは本当に工場なのか、プロキシなのか、それとも何か他のものなのか？

もちろん、同じ理由で、マネージャーは単なる悪以上に使用できます。EventManager本当に-which Dispatcherソースと興味がターゲットに派遣してから-queuesイベント。この場合、イベントの受信と送信の責任を分離することは理にかなっていEventます。個人は、出所や宛先の概念を持たない単なるメッセージであるためです。

a またはa を書くのと本質的に同じ理由でa DispatcherのEventインスタンスを書きます：GarbageCollectorFactory

マネージャーは、ペイロードが知る必要のないものを知っています。

それが、マネージャーのようなクラスを作成するための最も正当な理由だと思います。値のように動作する「ペイロード」オブジェクトがある場合、システム全体の柔軟性を維持するために、それは可能な限り愚かでなければなりません。個々のインスタンスに意味を提供するには、それらのインスタンスを意味のある方法で調整するマネージャーを作成します。他の状況では、マネージャーは不要です。

マネージャーは、悪いアーキテクチャの兆候である可能性がありますが、多くの場合、デザイナーに代わって彼のオブジェクトのより良い名前を考え出すことができないという兆候、または単に英語の事実を反映しているだけです（およびそのことに関するあらゆる人間の言語）は、毎日の実用的な概念を伝えるのに適していて、非常に抽象的な技術的な概念ではありません。

私の要点を説明する簡単な例：Factory Patternが命名される前は、人々はそれを使用していましたが、それを呼び出す方法を知りませんでした。だから、彼のFooクラスのために工場を書かなければならなかった誰かがそれを呼んだかもしれませんFooAllocationManager。それは悪いデザインではなく、ただ想像力の欠如です。

そして、誰かが多くのファクトリを維持し、それらを要求するさまざまなオブジェクトにそれらを渡すクラスを実装する必要があります。そして、彼は自分のクラスに電話をかけましFactoryManagerた。というのは、彼には言葉がIndustryまったく出てこなかったからです。再び、想像力の欠如の場合。

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

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

短い答え：それは依存します。

「マネージャークラス」にはいくつかの明確な形式があり、それらのいくつかは優れており、他のいくつかは悪いものであり、マネージャークラスを導入することが正しいかどうかは、ほとんどの場合コンテキストに依存します。それらを正しくするための良い出発点は、単一の責任原則に従うことです-あなたのマネージャークラスのそれぞれが責任を負っている（そしてそうでない）を正確に知っていれば、それらを理解する問題ははるかに少なくなります。

または、あなたの質問に直接答えるために：それは、悪いアーキテクチャを示すマネージャークラスの数ではなく、それらの多くが不明確な責任を持つか、またはあまりにも多くの懸念に対処することです。

それらは本質的に悪い設計を示していると言うのは簡単かもしれませんが、単一のタスクと責任を普遍的に包含することにより、プロジェクト全体で多くの良い結果をもたらし、コードの複雑さや他の定型的なコードを減らすのに役立ちます。

マネージャーの有病率は、デザインに対する判断力が低いためかもしれませんが、コンポーネント化されたデザインの他のコンポーネントやサードパーティのUIコンポーネント、または奇妙なインターフェースを備えたサードパーティのWebサービスとの不十分なデザイン決定や非互換性の問題を処理することもあります例として。

これらの例は、「複雑なコード」を1か所にカプセル化することで、全体的な複雑さを軽減し、さまざまなコンポーネントとレイヤー間の疎結合を促進する特定の状況で非常に役立つ場所を示しています。ただし、1つの落とし穴は、マネージャーをシングルトンとして作成するのが魅力的だということです。私はこれに反対することをお勧めします。もちろん、他の人が常に単一責任原則に従うべきだと提案しています。

マネージャクラスは、悪いアーキテクチャの兆候ですか？

あなたはあなたの質問に答えました：彼らは悪いデザインのサインである必要はありません。

EventManagerとあなたの質問の例を除いて、他の例があります：にMVCのデザインパターン、プレゼンターは、モデル/ビュークラスのマネージャーとして見ることができます。

ただし、概念を誤って使用した場合、それは悪い設計とおそらくアーキテクチャの兆候です。

クラスの名前に「マネージャー」が含まれる場合、神 クラスの問題（責任が多すぎる）に注意してください。クラスが担当するものをその名前で説明することが困難な場合、それは設計警告サインです。

悪いマネージャークラスは別として、私が見た中で最悪の名前は「DataContainerAdapter」でした

「データ」は、名前に含まれる禁止された部分文字列の別の1つである必要があります。すべてのデータです。「データ」は、ほとんどのドメインではあまりわかりません。

「-er」で終わるほとんどすべてのクラスと同様に、マネージャークラスは悪であり、OOPとは関係ありません。だから私にとっては、それは悪いアーキテクチャの兆候です。

どうして？「-er」という名前は、コードデザイナーが何らかのアクションを実行してクラスに変換したことを意味します。その結果、具体的な概念を反映するのではなく、何らかのアクションを反映する人工的なエンティティが存在します。これは非常に手続き的です。

それに加えて、通常、このようなクラスはいくつかのデータを取得して操作します。これは、パッシブデータとアクティブプロシージャの哲学であり、手続き型プログラミングにその位置を見出しました。それに気づいた場合、Managerクラスには何も悪いことはありませんが、OOPではありません。

オブジェクト思考は、オブジェクトが自分自身に対して何かをすることを意味します。ドメインを発見し、セマンティックネットを構築し、オブジェクトを生物、賢く責任ある人間にします。

そのようなオブジェクトを制御する必要はありません。彼らは何をすべきか、どのようにすべきかを知っています。そのため、ManagerクラスはOOPの原則を2回破ります。「-er」クラスであることに加えて、他のオブジェクトを制御します。しかし、それはマネージャーに依存します。彼がコントロールする-彼は悪いマネージャーです。彼が調整すれば、彼は良いマネージャーです。そのため、MVCの「C」文字を「コーディネーター」と綴る必要があります。

この質問に対する正しい答えは次のとおりです。

1. 場合によります。

ソフトウェアの作成中に発生するすべての状況は異なります。多分あなたは、マネージャークラスが内部的にどのように機能するかを誰もが知っているチームにいますか？そのデザインを使用しないのは完全に狂っています。または、マネージャーの設計を他の人にプッシュしようとしている場合は、悪い考えかもしれません。しかし、それは正確な詳細に依存します。