数クラス対20クラス？膨満についての質問
アウトソーシング会社の仕事を評価したところ、彼らは仕事を可能な限り多くのクラスに分割する傾向があることがわかりました。各クラスはテスト可能です。ある意味でこれは称賛に値するように見えますが、彼らはそれを極端にしており、誰もそれらを制御することができないようです。
最近、私は最大3つのクラス（1つはデータ、1つはコントローラー、1つはビュー）として実装する必要のあるシンプルなUIピースであるべきものを見つけ、実際には約20のクラス（例：基本クラスと複数の派生クラス）とプロトコル、最後に約70のソースファイル（Objective C .mファイルと.hヘッダー）を必要とします。精巧なテストコードにもかかわらず、彼らのコードはほとんど機能せず、常に壊れています。
彼らは、SOLIDおよび/または「大規模なクラス」問題についての漠然とした話でこれを正当化します。
このコードはすでに書かれています。誰もそれを設計することは許されなかった。実装を批判することはできますが、実際にはデザインには影響しません。
では、より良い雇用を求める以外に、Outsourcing Companies Gone Wildに対処するための優れた戦略とは何ですか？そして広大？
問題xを考えると、20が間違っていて、3が正しいとどうして言えるでしょうか
方法は次のとおりです。
良い日には、私の脳は一度に7つの物を保持できます。それでおしまい。もういや。時々それは5つだけです。
だから20は多すぎる。 xが何であっても構いません。
ただし、それぞれの後ろに5つのクラスが隠れている4つの抽象化は問題ありません。そしてええ。それはまだ20です。
私が言っているのは数の問題ですが、組織も同様です。これらの人が少人数のクラスで気が狂っているが、それらを整理するために何もしていない場合、彼らは本当の問題を引き起こしています。スタイルに慣れていないというだけではありません。それは彼らがあなたに一度に7つ以上のことを思い出すように頼んでいるということです。
これは有効なスタイルです。単にそれに反対するように外れないように注意してください。代わりに、読みやすさを向上させるために信頼できる抽象化の必要性を強調してください。それを理解するために抽象化に飛び込む必要がある場合、それは機能していません。
彼らは物事をこの小さなものに分解することに決めました。理にかなった方法ですべてをまとめるのは彼らの責任です。
コードを見ない限り、彼らが良い仕事をしているか悪い仕事をしているかはわかりません。
しかし、通常は小さなクラスでコードを分割することをお勧めします。この戦略は、コードの適切な構成がわからない場合に非常に一般的です。本当に必要なクラス、それらの構成方法、ドメインの知識がまだ十分ではないなどです。
たぶん、あなたはこの行で何かを主張して、一部のクラスが現在は1つのクラスだけであるほうが理にかなっていることをチームの他のメンバーに納得させることができます。 Martin Fowlerによる記事があります。
精巧なテストコードにもかかわらず、彼らのコードはほとんど機能せず、常に壊れています。
これは、必ずしも小さなクラス戦略の問題ではありません。たぶん、このすべてのクラスがうまく連携しているかどうかを確認するには、プロジェクトにいくつかの統合テストが必要です。
あなたの質問への回答は、「はい」または「いいえ」のバイナリにすることはできません。場合によります。これらの20のクラスが、設計の悪さによるクラスの爆発の結果なのか、構造化された設計に対する十分な考慮によるのかによって異なります。例：古いコードの一部をリファクタリングしているときに、ブリッジパターンを適用することにより、クラスの数をx * y => x + yから変換できることに気付きました。 デコレータパターンと考えると、同じことが起こります。
だから私が言ったように、この20がx * yまたはx + yによるものかどうかを理解する必要があります。
MVCに4つ以上のクラスが必要な場合があります-コントローラーが本当に複雑なことを行う必要がある場合、コントローラーをどんどん大きくするのではなく、別のクラスで複雑さを抽出する方が良いです。または、ビューに複雑なサブビューがある場合、特にそのサブビューを他の場所で再利用できる場合。
とはいえ、追加のクラスはすべて複雑になります。したがって、smallの複雑さの量を別のクラスに削除することは通常悪いことです。 3つのクラスが20になった場合、コントローラーの処理が非常に複雑でない限り、これはここで発生した可能性があります。