c# - クラスを分割する場合

Question

さて、私は「アーキテクチャ」と呼ばれる次のクラスを持っています。このクラスには多くのメソッドがあります (約 50 だと思います)。

そこで、これらのメソッドと「Architecture」の構成を含む「ArchitectureProcessor」クラスを作成しました。これは良い習慣ですか？

つまり、1 つのクラスに 50 個のメソッドを持ちたくないということです。非常に乱雑に見えるので、できる限りすべてのクラスを分割しようとすると、この問題がよく見つかります。

Answer 1

あなたの 50 メソッド クラスはおそらくやりすぎです。

コメントで既に言及されているように、単一責任の原則に従うようにしてください。つまり、クラスは 1 つの責任のみを持つべきです。複数の責任がある場合は、異なる責任に基づいてクラスを複数のクラスに分割してみてください。

単一責任の原則は、SOLIDという造語の原則のより大きなグループの一部です。

• 単一責任の原則
• オープン/クローズの原則
• リスコフ置換原理
• インターフェース分離の原則
• 依存性逆転の原則

これらの原則はすべて、似たようなコードから離れるのに役立ち、オブジェクト指向プログラミングの優れたガイドとなります。

Answer 2

私の意見では、それはクラスのサイズではなく、クラス内でグループ化する機能に関するものです。理論的には、どのようなサイズのクラスでも適切なクラスにすることができます。

Answer 3

分割のために分割しないでください。インターフェイスをぎこちなくしているだけです-architecture.Foo()書く必要があるのではなく-そこに識別子architecture.Process.Foo()を詰め込むのは自然ではありません...Process

メソッドが多すぎる場合、クラスが階層全体を単独で表現しようとしている可能性がありますか? が建物に関するものであると仮定するArchitectureと、建物のフロアも表現しようとする可能性があるため、 のようなメソッドがありますRoomCountInFloor(int floorNumber)。その場合、Floorクラスが必要でArchitectureあり、フロアのコレクションを含める必要があるため、書くことができますarchitecture.Floors[5].RoomCount- よりもはるかに優れていますarchitecture.Process.RoomCountInFloor(5)よね?

もう 1 つの可能性は、使用しているサービス メソッドが多すぎることです。その場合、それらのサービス メソッドをサービス クラスに入れたいと思うかもしれません。以前行った Java プロジェクトでは、多くのサービス メソッドを使用して、クラスの 1 つが使用していたすべての一時ファイルを管理する必要がありました。これらのサービス メソッドをそのクラスに追加する代わりに、そのためのTempFileManagerクラスを作成しました。その分割により、いくつかのメソッド (カプセル化とすべて) を追加する必要がありましたが、その方法ではるかに整理されており、別のプロジェクトで同様の一時ファイル管理が必要になった場合は、そのクラスをコピーするだけで済みます。

直接表現するものを処理するために 50 個のメソッドが必要になる可能性もありますがArchitecture、これらすべてのメソッドを 1 つの大きなファイルに含めるのは面倒です。その場合、C# の部分クラス機能の使用を検討する必要があります。

Answer 4

クラスに複数の責任がある場合は、すぐにクラスを分割する必要があります。

• あなたの読書クラスは書き始め、分裂します。
• ロジック クラスは、分割されたユーザー インターフェイスの更新を開始します。