数か月前に書いたいくつかのコードをリファクタリングしていますが、今では小さなクラス (いくつかのプロパティ、2 ～ 4 つのメソッド、1 ～ 2 つのイベント) を作成していることに気付きました。
これが本来あるべき姿ですか？それとも、これもコードの匂いですか？
つまり、クラスがその責任を果たすために多くのメソッドを必要とする場合、それはそうあるべきだと思いますが、多くの小さなクラスが特に良い習慣であるかどうかはわかりませんか?
1272 次
3 に答える
4
たくさんの小さなクラスは大丈夫そうです:)
特に、各クラスにインターフェイスを実装させ、さまざまな共同作業者が直接相互に通信するのではなく、それらのインターフェイスを介して通信するようにすると、いわゆる柔軟な設計(ドメイン駆動設計の用語)を実現できるはずです。カップリング。
重要な操作が入力と同じタイプの出力を持つように煮詰めることができれば、Evansが「操作の閉鎖」と呼んでいるものを実現できます。これは特に強力な設計手法であることがわかりました。
SRP を適用するときに起こりがちなことは、すべてのクラスが最初は小さくても、常にリファクタリングを行うことです。ときどき、いくつかの特定のクラスが以前に想定していたよりもはるかに豊富である可能性があることを明らかにする洞察が殺到します。
それを行いますが、永遠にリファクタリングを続けてください:)
于 2009-12-26T18:54:33.867 に答える
1
焦点を絞った責任を持つ小さなクラスの多くは、srp のすべてです。ですから、そうです、これは、srp 支持者に関する限り、物事が「想定される」方法です。しかし、システム内のクラス数が爆発的に増加しているため、実際にどこで処理が行われているかを覚えたり、直感的に把握したりすることが非常に難しくなり始めていますよね? あなたは確かに、srp に伴う (通常は不必要な) 複雑さの増加である、新しいコードの臭いを暴露しています。私はそれについてのエントリーをここに書きました。あなたが同意するかどうかを確認してください。
于 2009-12-26T19:39:08.003 に答える
1
私はあなたが中間の道を見つけなければならないと思います。クラスが多すぎると、やり過ぎになることがあります。私の側からは、より小さなレベルで懸念を分離しようとします。物事が進んでいる場合は、より粗い粒度でリファクタリングします。
最初に、メソッドを抽出して個別の懸念事項を記述します。専用の責任「抽出クラス」を形成するデータ (インスタンス + 静的フィールド) のメソッドのグループを確認できる場合。しばらくして、パッケージ内にさまざまなクラスのグループが表示される場合は、「パッケージを抽出」してください。
この (爆発) アプローチは、最初から多くのクラスとパッケージを作成するため、より自然であることがわかりました。しかし、これも状況によって異なります...: 最初に大きなコンポーネントが表示される場合は、専用のパッケージ構造を既に作成しています。
より具体的なヘルプを提供するために、コードに関する詳細がいくつかあるかもしれません:)
于 2009-12-27T14:30:46.513 に答える