wpf - 悪い OOP 設計から良い OOP 設計に移行するには?

Question

私は、OOP 設計の良い方法と悪い方法について多くのことを読んでいます。あなたのデザインが悪いか良いかを知るのは素晴らしいことです. しかし、悪いデザインから良いデザインへと移行するにはどうすればよいでしょうか? インターフェイス (xaml) とコードビハインドをメインのビジネスロジッククラスから分割しました。その最後のクラスは大きくなっています。私はそれを小さなクラスに分割しようとしましたが、今は立ち往生しています。大規模なクラスを分割する方法についてのアイデアはありますか? メインクラスには、さまざまなタイプのデータのリストが 1 つあります。合計だけでなく、個々のタイプについても計算しています。コードビハインドで処理されるイベントから呼び出されるこれらの計算を実行するメソッドがあります。ここからどこへ行くべきか？

追加情報：

このプロジェクトを開始して、すでに約 6 か月が経過しました。私は何年もの間、オブジェクト指向言語 (最初は c++、java、そして現在は c#) を扱ってきましたが、このような大規模なプロジェクトに携わったことはありません。最初に間違ったターンをしたと思うし、これらを修正する必要があると思う。現時点では、このプロジェクトの詳細を特定することはできません。デザインに関する本を 1 冊か 2 冊注文します。すべてのクラスを分離した場合、それらを元に戻すにはどうすればよいですか? この方法を最初のリリースまで続けて、その後、2 番目のリリースのためにパーツを再構築する方が良いのではないでしょうか?

score 10 · Accepted Answer

練習して読む。繰り返す：）

いくつかの推奨本：

Robert C Martin によるクリーンなコード
GoF 設計パターン
Martin Fowler によるリファクタリング

個人的には、Head First Design Patterns も気に入りましたが、このスタイルは万人向けではないかもしれません。C# 3.0 Design Patterns と呼ばれる同様の本があります (ora.com を参照)。それは同じものの多くを持っていますが、より伝統的な方法です.

score 4 · Accepted Answer

物に対する考え方を変える。すべてのオブジェクトには、非常に具体的な責任が 1 つある必要があります。「MainBusinessLogic」などの一般的な名前のクラスがある場合は、おそらく何か問題があります。

始めるのに最適な場所: David West のObject Thinkingを読んでください。

score 4 · Accepted Answer

Code Completeを手に入れることを強くお勧めします。そんな疑問に的確なアドバイスをくれる本です。

大規模なクラスを分割する方法に関する質問への簡単な回答を提供するために、経験則として、クラスが 1 つのことだけを担当するようにします。そのように考え始めると、当てはまらないコードをすぐに特定できます。何かが属していない場合は、それを新しいクラスに分解し、元のクラスから使用します。

編集：その考えを「メソッド」レベルに落とし込みます-メソッドが1つのことだけを担当するようにします。大きな (50 行を超える) メソッドを再利用可能なコードの塊にすばやく分割するのに役立ちます。

score 3 · Accepted Answer

メインクラスには、さまざまなタイプのデータのリストが1つあります。合計だけでなく、個々のタイプについても計算を行っています。コードビハインドで処理されるイベントから呼び出されるこれらの計算を実行するメソッドがあります。ここからどこへ行くべきかアイデアはありますか？

リストの内容に基づいて計算が多い場合、カスタマイズされたリストクラスに操作を移動することを検討しましたか？特定のタイプの操作についても同じことが言えます。おそらく、タイプ内に存在する可能性がありますか？

異なるタイプで同様であるが異なる操作を実行するという観点から、エンティティを均一に処理できる状態パターン（switchステートメントの代わりとしてこれを参照）の使用を検討してください。

多くのOOPは、「トップダウン」/マイクロマネジメントアプローチを破棄し、「ボトムアップ」/自給自足アプローチを検討することです。どちらのアプローチも単独では「正しい」ものではないことを覚えておく価値があります。保守可能なコードを作成することは、多くの考えを必要とし、通常は経験を通じて発展する賢明なバランスを見つけることです。

score 3 · Accepted Answer

これは、ここにあるいくつかの優れた本の提案への単なる追加です。

OO が上手になればなるほど、オブジェクトのサイズが小さくなっているように見えます。オブジェクトのサイズを小さくしようとしているわけではありませんが、それは起こっているようです。

それらを小さくし、単一の責任を持ち、使いやすく理解しやすいものにすることはすべて重要です。各オブジェクトは可能な限り防弾に近いものにする必要があります。パラメーターを確認し、オブジェクトが無効な状態になることを決して許可しないでください。ドキュメントですべての有効な状態を明確に定義します。

クラスを作成するときはいつでも、そのクラスのテストを作成します。コードをテストするだけでなく、独自のデザインを使用する必要があります。常にその「外からの視点」で授業を考えてください。あなたのクラスを使っている人にあまり多くを求めていないことを確認し、あなたが彼に求めていることはすべてインターフェイスに文書化する必要があります。利用可能なテストフレームワークがない場合は、多くの場合、簡単なメインをクラスに挿入します。つまり、コードの使用方法の例を同じファイルに配置します。

コーディングでは、私の時間のほとんどは、他の人が何をしたかを把握するために費やされます。既知の API または十分に文書化された API を使用してコードを作成できれば、私の仕事は簡単になり、スケジュールも大幅に短縮されます。

デザインファーストは難しい場合があります。コーディング能力は、スポーツ能力と同様と考えてください。私たちのほとんどは私道でプレーしますが、地元のスポーツチームでプレーする人もいます。複雑なプロジェクトで優れた事前設計を行うことは、ナショナルリーグのプレーヤーの仕事です。彼らは 100 万人に 1 人です。これを受け入れて、変更の計画を立ててください。反復はあなたの友達です。(ちなみに、私たちのほとんどは簡単に州レベルに到達できると考えていますが、そうではありません)。

score 3 · Accepted Answer

Robert C Martin によるBrian の推奨の Clean Code に加えて、"Uncle Bob's" SOLID Principles of Object Oriented Designを読みたいと思うかもしれません。

彼がHanselminutes Podcast 145で SOLID Principles について話し、.NET Rocksできれいなコードについて話しているのを聞くことができます! #388 を表示します。.NET Rocksで彼と一緒にいることは他にもあります。Show #410ですが、彼が話していることはあなたの質問とはあまり関係がありません。

3 つのポッドキャストの中で、私は Hanselminutes を好みました。

score 2 · Accepted Answer

Martin Fowler によるRefactoringは、ソフトウェアの設計を壊さずに変更する方法についての優れた本です。

デザインパターンはアルゴリズムと同様に機能しますが、オブジェクトを組み合わせてさまざまな有用なタスクを実行する方法を説明します。

最後に、 Martin Fowlerは、アプリケーションに役立つさまざまなデザインパターンを提供しています。たとえば、パッシブビュー

score 1 · Accepted Answer

Michael Feathers の"Working Effectsly with Legacy Code"は非常に優れているはずですが、私自身は読んだことがありません。

「パターンへのリファクタリング」も同様です。

score 1 · Accepted Answer

助けを借りずに複雑な「課題」に取り組み、他の人がそれをどのように行うかを見ることは、私にとって大きな学習経験であることがわかりました.

特に 1 つの任務は、銀行のようなプログラムを作成することでした。このプログラムでは、トランザクションを追跡し、獲得した利息などを計算できるようにする必要がありました。それは本当に私の最初の OOP プログラムであり、その複雑さのために本当に素晴らしいものでした。エラーを起こさずに直線的なスタイルでそれを行うのは (初心者にとって) あまりにも混乱します。

score 0 · Accepted Answer

よりテストしやすいコードを書いてみてください。これだけでも、改善された OOP プラクティス/設計概念を調査して実装する必要がありました。

score 0 · Accepted Answer

私は自分にとって何がうまくいくかしか言えません。同じように働く人を実際に見つけたことがないので、それがあなたの助けになるかどうかはわかりません.

基本的に、私のアプローチはクラスをできるだけ少なくすることですが、少なくすることはありません。

まず、情報を保存する必要があるのは、A の時点で情報を受け取り、B の時点でそれを必要とする場合のみです。情報を取得して同時に作業する場合、情報を保存する必要はないかもしれません。 .

第二に、あなたはそれで何をしますか？特定の単純化された方法で反復する場合は、それを命令セットと見なし、それを操作するプログラムを命令セットのインタープリターと見なすことができます。その場合、インタープリターを使用してバイトコード命令セットを実際に設計し、その命令セットで情報をエンコードすることをお勧めします。

第三に、情報はどのくらいの頻度で変更されますか? 一部の情報が頻繁に変更されない場合は、部分的な評価 (つまり、コード生成) を使用できる場合があります。つまり、頻繁に変更されない情報を取得し、それを使用してアドホックプログラムを生成します。このプログラムは、プログラム全体がその情報で行うことを実行しますが、はるかに高速です。コードジェネレーターは、入力情報の一部、つまりゆっくりと変化する部分のみを処理するため、簡単に記述できます。

最近目にするデータ構造の多くは、UI をサポートするために存在します。これは明らかに、ユーザーが気にするオブジェクトを保持していません。理想的には、気にする必要もありません。そこで私は、そうした面倒なことをすべて隠す UI 用の DSL を作成しました。

イベントや通知は可能な限り近づかないでください。イベントや通知は特定の時点で発生し、状態の漸進的な変化を表すためです。削除、重複、または順序の誤りが発生する可能性があることを非常に心配する必要があります。多くの場合、単純なポーリングスタイルは「効率が悪い」という理論に基づいて使用されますが、実際には逆のことがよく起こります。

したがって、クラスなどのテクノロジーに夢中になっている人を見ると、たいていの場合、データ構造が大きくなりすぎていることが原因です。

ただの私の反対票餌...

score 0 · Accepted Answer

Refactoringよりも、 Safariで利用可能で検索可能なFeather's Working Effectively with Legacy Codeをお勧めします。I Don't have much Time and I Have to Change ItやMy Application Has No Structureなどの便利で共感的な章でいっぱいです。

考慮すべき視点:

設計品質テストの自動化 - 設計上の意思決定のクロスチェックとして、設計品質に関する指標を提供するツールを探します。
コードのテスト容易性 - リファクタリングのいずれかが、テスト駆動型開発、単体テストの作成、または機能テストの作成に役立ちますか、または妨げますか? 統合されたアーキテクチャの大部分をテストするのはどれほど難しいでしょうか?
正当化 - 冷笑的な CYA から経営陣まで、そしてさらに重要なこととして、チームが再設計を信じられるように、これらの決定をどのように擁護しますか。変更が行われた理由を簡単かつ一貫して説明できますか?また、その説明は 6 か月以内に簡単に見つかりますか?

デザインの個人的な好み、特にリファクタリング:

概念のためのクラス- 明確な概念が 1 つしかない場合、疑わしい場合は、1 つまたは複数のメソッドの動作として暗示するのではなく、クラスにラップする必要があります。
責任を伴うささいなことをたくさん伝えると、考えやすく、監査しやすくなります。設計が現実の世界にどのようにマッピングされるかについて疑問がある場合は、各クラスの責任を書き留める、古い責任駆動設計アプローチに戻ります。これが難しい場合は、各クラスが何をするかについての概念が混乱しているか、やりすぎている可能性があります。
物事が規則的であれば、物事が大きくても怖がらないでください。場合によっては、例: GUI 上の多数のイベントハンドラーでは、メトリクスが推奨するよりもはるかに多くのメソッドまたはプロパティを持つクラスが合法的に存在することがあります。

wpf - 悪い OOP 設計から良い OOP 設計に移行するには?

12 に答える 12

Related

Reference