9

私のアプリにはController、mainメソッドで開始されたものがあります。コントローラは、フック、データベース接続、UI、別の接続などを初期化します。プログラムの状態のほとんどを保持します（いいえ、シングルトンではありません）。別の例では、コマンドの解釈と送信を処理するボット用のコントローラーがあります。どちらもかなり大きなファイルです。

私は神のオブジェクトについて読みましたが、それを分割する方法を本当に知りません。ボットでインタープリターとディスパッチャーを分割すると、恐ろしいコールチェーンが作成されます（のようなものgetBot().getParser().getOutput().sendMessage(recipient, message)）。同様に、最初のコントローラーでは、物事を分割すると、フィールドといくつかのエイリアスユーティリティメソッドを保持するDataオブジェクトが作成されます。それらを分割すると、事態はさらに悪化します。そして、あなたがその維持不可能であると考える前に、それは実際にはそうではありません。ボットコントローラーも作成していませんが、何が起こっているのかはわかっています。

ただし、問題は、Botクラスの長さが2000行（Javadocコメントを削除した場合はおそらく短い）であり、Botの長さが約1000行であるということです。たくさんの線=神オブジェクト。しかし、プロジェクトの1つまたは2つのコアクラスで問題ありませんか？

4

4 に答える 4

11

「たくさんの行」は、クラスが神オブジェクトであることを意味するものではありません。これは、何かをリファクタリングする必要があるかどうかを判断するためのひどいひどいベンチマークです。いくつかのものは非常に複雑であり、複雑で本質的に大きなオブジェクトを保証します。神オブジェクトのアイデアは、クラスが行うことです。

たとえば、次のようなオブジェクトを作成した場合

DoMyTaxes()
GiveMeHugs()
LogThisError()
StartGameLoop()

100行のコードしかない場合でも、オブジェクトは神オブジェクトと見なされます。基本的な考え方は、上記のすべてが（ビジネスロジックの範囲の終わりでは）完全に無関係であるため、なぜ世界でそれらがすべて同じオブジェクトの一部になるのかということです。ハグを長持ちさせることにした場合、税金を台無しにしてしまう可能性があります。IRSを入力します。

ただし、物理シミュレータで作業している場合、たとえば、Classical()クラスには次のようなメソッド/オブジェクトがあります。

Space()
Time()
Velocity()
Speed()
Mass()
Acceleration()
Gravity()
Force()
Impulse()
Torque()
Momentum()
AngularMomentum()
Inertia()
MomentOfInertia()
ReferenceFrame()
Energy()
KineticEnergy()
PotentialEnergy()
MechanicalWork()
VirtualWork()
DAlembertsPrinciple()

（ウィキペディアの礼儀）

このオブジェクトは神オブジェクトではありません。複雑なオブジェクトです。ニュートン物理学を扱うすべてのものがそれを通過しますが、それは神オブジェクトではありません..それは本当に本当に大きなオブジェクトです。上記は、数千行のコードになる可能性があります。

Quantum()言うまでもなく、オブジェクトはさらに複雑になります。

繰り返しになりますが、アイデアはプログラムの動作に関するものであり、データフローに関するものではありません。

単一のオブジェクトがアプリのデータの多くを保持するかどうか、またはほとんどのフローが単一のオブジェクトを通過する必要があるかどうかは関係ありません。保守性により大きな影響を与えるのは、単一のGod Class（tm）があまりにも多くの動作（ビジネスコード）を保持している場合です。

問題があると思われる場合は、さまざまな形式のメディエーション、または依存性注入などの醜いパターンを実装してみてください。

于 2010-10-25T02:53:37.987 に答える
3

クラスのサイズと複雑さに不安がある場合は、通常、より良い設計が行われる可能性があることを示す良い指標になります。ただし、サイズだけで測定しないでください。クラスが理解しやすく、理解しやすいが、多くのコードが含まれている場合、それは必ずしもリファクタリングの候補であることを意味するわけではありません。私は人々がこれに夢中になっているのを見てきました、そして物事を小さくするために彼らが作成する混乱は元のコードよりもはるかにひどいものでした。一方、私はクラスを端から端まで何度も読み通しましたが、それでもクラスが何をしているのかわかりませんでした。

私が尋ねる質問は、これを別の開発者に渡した場合、彼らはそれを簡単に理解して維持できるでしょうか？

答えが「はい」の場合、何もする必要がない可能性があります。そうでない場合は、リファクタリングが必要です。

神オブジェクトに関して、あなたの投稿を読んで、それはこのクラスがやりすぎているように聞こえます。まず、開始点として状態をモデルオブジェクトのセットにリファクタリングできるかどうか疑問に思います。次に、クラスはある種の構成ファクトリのように見え始めます。

于 2010-10-25T02:33:25.290 に答える
2

物理学/運動エンジンは、言語通訳者から確実に分離する必要があることをお勧めします。言語インタープリターは、物理エンジンのパブリックメソッドとプロパティの一部にアクセスする必要がありますが、ロボットの2つの側面が同じクラスにある必要がある理由はありません。言語通訳者自体は、移動エンジンと同様に、いくつかのクラスに細分することができます。マスターコントロールオブジェクトが存在する可能性がありますが、コードの量は比較的少ないはずです。それ、主要な移動エンジン、および主要な言語エンジンはすべて、それらを構成するオブジェクトにほとんどの作業を委任する必要があります。

于 2010-10-26T01:46:13.760 に答える
0

ここでの重要な原則は「結束」だと思います。

DoMyTaxes()
GiveMeHugs()
LogThisError()
StartGameLoop()

..まとまりがありません。

何かのようなもの ：

GiveMeHug()
GiveMeKisses()
GiveMeHugs(int noOfTimes)
GiveMeHugs(int noOfTimes, Person person)
GiveMeHugsAndKisses()

..すべての方法がかなり似ているので、まとまりがあります。クラスに1000個のまとまりのあるメソッドを含めることができますが、クラスの責任はまだ制限されているため、それでも神オブジェクトにはなりません。

于 2013-02-15T09:57:07.660 に答える