OOPのクラス設計にどのように取り組みますか？

オブジェクト指向ソリューションを設計しようとすると、通常、CRCモデリングを使用して、クラス名（名詞）、それらが行うこと（動詞）、および他のクラスとのコラボレーション方法をリストします。

このブログには、この名詞動詞のアプローチについて以下のことを述べています

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

私の質問は、オブジェクト指向アプローチを使用するためのより良いモデリング手法が存在するかどうかです。

公正に、彼はその主張に「楽しみ」を加えました。

今日まで、私は「名詞と動詞」アプローチを使用してシステムをモデル化することから始める傾向がありますが、TDDはこのアプローチが間違ったことに焦点を当てることを教えてくれることを長年にわたって知っています。この意味で、ブロガーにはポイントがあります。しかし、それが私たちの心の働き方ではなく、誤ったアプローチであるかどうかはわかりません。

ここで少し挑戦したい場合は、読み上げを止めて、英語を使用してMonopolyゲームをモデル化してから、ここに戻ってください。

ボード、スペース、カード、サイコロ、ピースなど、私たちがよくやり取りするオブジェクトをすぐに見たいと思うかもしれませんが、それはロジックの大部分が行く場所ではありません。これらのオブジェクトのほとんどは完全に馬鹿です。必要に応じてデータ。

しかし、テストを書き始めるとすぐに、どのオブジェクトがどのゲームでも最も重要であることに気付きます：ルール。

ゲームを初めて入手したときに一度読んだ小さな紙切れを思い出してください。紛争が発生するまで再びやり取りしないでください。コンピュータ化されたバージョンはそのようには動作しません。プレーヤーがしようとするすべてのことは、コンピューターがルールを調べて、許可されているかどうかを確認します。

あなたがそれについて考えるとき、あなたは同じことをしますが、紙ベースのルールを読むのに時間がかかり、あなたの脳は合理的なキャッシングシステムを持っているので、あなたは頭の中でルールを調べます。コンピュータは、おそらくルールを再び読みやすいと思うでしょう-ルールがデータベースに保存されていない限り、その場合、ルールもキャッシュされる可能性があります。

そして、これがTDDが実際にデザインを運転するのにとても人気がある理由です。それはあなたの思考プロセスを適切な場所に素早く導く傾向があるからです：

モノポリーゲームのテストを書くつもりだと思うとき。セットを見て、オブジェクトを見つけようとするかもしれません。だから、私たちはこれらのピースを持っています。それらのためにいくつかのテストを書きます。

たぶん、基本クラスMonopolyPieceがあり、各タイプのピースはそれらから派生します。DogPieceから始めます。最初のテスト...ああ。実際、ここにはロジックはありません。はい、各ピースは異なる方法で描画されるため、DogDrawerが必要になる場合がありますが、ゲームを肉付けしている間、画面に「D」と書きたいだけです。最後にUIにスパイスを加えます。

テストする実際のロジックを見つけましょう。これらの家やホテルはたくさんありますが、テストは必要ありません。お金じゃない プロパティカード、ありません。等々。ボードもステートマシンに過ぎず、ロジックは含まれていません。

手に3つのものが残っていることがすぐにわかります。チャンスとコミュニティチェストカード、サイコロのペアとルールのセット。これらは設計とテストの重要な部分になります。

名詞と動詞を書いたときにそれが来るのを見ましたか？

実際、Robert MartinのAgile Principles Patterns and Practicesには、TDDを使用してボウリングスコアカードアプリを具体化して、明らかに面倒だと思われるあらゆる種類のものを見つけようとする素晴らしい例があります。

私はそのような方法が私にとって有益だとは思っていません。実際、それらを使用すると、さらに混乱することがわかりました。Robert C. MartinのCoffee Makerをご覧ください。彼もこの種のアプローチを使用しているとは思いません。

すぐに気になるのは、リンク先のCRC記事でその人が出会う解決策です。顧客/注文のコラボレーションは、とにかく書かれたものではなく、価値があると思うものではありません。このモデルでは、クラスのステータスに値する顧客について特に興味深いものはありません。「顧客」であることに関して興味深いのは、そのPersonに関連付けられた1つ以上の注文があることです。

大学のモデルも。学生と教授の間で共有することができ、おそらく共有すべきものがたくさんあります。さらに、大学のキャンパスでは多くの場合無料で許可されているように、教授がクラスを受講するとどうなりますか？

設計ツールキットの1つの要素である、やりがいのある練習になると思います。少なくともデザインにアプローチする唯一の方法だとは思いません。率直に言って、共通性/変動分析アプローチの方が便利だと思います。日常生活の中で抽象化を分類する際に私たちが行うことを非常に密接にモデル化するように思えます。

編集：ちょうどその2番目のブログの半分を読んで、私はかなりそれに同意することを言わなければなりません。残りを読んで、学習の観点からそれが提供するものを確認する必要があります。

私の意見では、懸念を分離し依存関係を減らすためにコーディングするときにクラスを追加（および削除）する必要があります。設計パターンに堪能であることは、おそらくリファクタリングと単純化の可能性を見るための良い策です。

クラスは一般的に、私の経験では、名詞/動詞のカテゴリにきちんと分類されませんが、名詞/動詞のクラスとさまざまなパターンクラス（工場、シングルトン、戦略パターンなど）およびその他のマネージャークラスが混在することになりますアプリケーションの側面に対応します。

重要なことは、あなたの目標はクラスを見て、それが何をするかを推測し、そのクラスを変更するだけでそれを変更できるようにすることです。アプリケーションのある側面のコードがクラスに分散されるほど、それを追跡、管理、拡張することが難しくなります。