Bob Martinの本「C＃でのアジャイル開発の原則、パターン、および手法」に対する批判

10人の開発者に設計に関する最高の（または価値のある）本について尋ねると、そのうち少なくとも6人がボブ・マーティンの本Principles、Patterns、and Agile Development Techniquesを命名します。 この後、「おじさん」ボブの著作の興味深い点で彼らを見せれば、彼らのほとんどは額を困惑させ、心をいくらか変えるでしょう。

このメモを読むときは、常識を含めて、神聖なものへの攻撃とは考えないでください。 結局のところ、圧倒的なプロジェクトで手に傷跡が少なくなり、「パターン」という言葉で膝が少し震えた数年前にそれを読むことはかなり可能です。 だから、多分あなたは新しい経験の高さから「古典」を見るべきでしょうか？


本の最初のページから、Martinsはファンを非常に軽く投げて、次のように本を開始します。

「私の経験では、.NETプログラマはJavaやC ++で書く人よりも弱いことがよくあります。 例外があることは明らかです。 ただし、リスナーを何度も何度も見て、.NETプログラマーは通常、ソフトウェア開発方法、設計パターン、および原則などにあまり精通していないと結論付けられました。 現在の.NETプログラマーは、これらの基本的な概念についてまったく聞いていないことがよくありました。 この状況は変えなければなりません 。

この本に取り組んでいる間、.NETに捧げられた本の表紙に自分の名前を載せるかどうか疑問に思うことがよくありました。 .NETと、このプラットフォームに関連付けられているすべての否定的なビューに関連付けたいかどうかを自問しました。 しかし、それを拒否することの使用は何ですか？ 私は.NETプログラマーです。 いや！ 私は柔軟な.NETプログラマーです。 そしてそれを誇りに思っています。」

それでは、文盲の.NETチークがマーティンの仲間から学べることを見てみましょう。

原則

一般に、SOLIDのすべての原則の説明は非常に曖昧に思えました。 一方では、それらの多く（DIPやOCPなど）は非常に厳密に表現されています。DIPは特定の型の変数の使用を禁止し、OCPは再コンパイルなしの拡張を意味します。 一方、時には、これらの原則を賢く使用する必要があるという実用的なメモがすり抜けます。

興味深い点は次のとおりです。

「柔軟なチームはこれらの原則（SOLIDを意味する）を悪臭の除去にのみ適用します。 悪臭がなければ、原則は当てはまりません。 原則であるという理由だけで原則を無条件に守るのは間違いです。 悪臭をなくすための原則があります。 これらは、システム全体に豊富に水をまく必要がある香水ではありません。 原則を過度に遵守すると、不必要な複雑さの悪につながります。」

一方で、これは非常に実用的な観点ですが、一方で、従うべきタイミングと従わないタイミングに関する追加のルールを導入するために、このような厳格なガイドラインに従う必要があるのはなぜですか？

加えて、ここでは原因と結果が混同されているように思えます。原則は、設計における「最愛の人」を定義するためにまず必要であり、それらを排除するのにはまったく役立ちません。

以下は、単に違反できない原則の説明です。

Lsp

「派生クラスを作成するときにベースクラスを変更する必要がある場合は、おそらく設計に欠陥があります。」

または、別の選択肢があります。私たちは、進化設計が重要な開発アプローチである現実の世界に住んでいます。

「LSPの原理は、実際のプログラムに応用できますか？ 私が数年前に取り組んだプロジェクトから取った例を考えてみてください... 1990年代初頭に ... "
オリジナルの本は2006年半ば（C＃2.0と一般化のリリース後）にリリースされましたが、ここ数年前-これは1990年代の始まりです

「リスク代替原理は、OCP原理を実装するための主要なツールの1つです。」
OCPを達成するためのオプションの1つはポリモーフィズムであり、LSPはポリモーフィズムが期待どおりに機能すると言います。 たとえば、コールバック関数に基づいて、OCPを達成するためのその他のオプションがあります。

すでにLSP原則の形式化について話している場合は、コントラクトについて、継承の正しい実装のためのそれらの役割について話し合う必要があります。 契約は本で言及されていますが、文字通り通り過ぎます。

ディップ

この原則についてのより詳細な批判は、記事「依存関係の逆転の原則に関する批判的な見方」に記載されています。

しかし、これは非常に喜ばれた非常に感情的な結論です：

「実際、このような依存関係の逆転は、オブジェクト指向設計の大きな兆候です。 プログラムがどの言語で書かれているかは関係ありません。 依存関係が逆になっている場合、オブジェクト指向設計になります。 それ以外の場合、設計は手続き型です。」
非常に物議を醸す声明、同意します！

Opc

Open-Closed原則の著者がBob Martinではなく、Bertrand Meyerの著書 " Object-Oriented Design of Software Systems"にあることを知っている人はあまりいません。 同時に、ボブ・マーティンが彼自身の方法でこの原則を解釈することに注意を払う人はさらに少なくなりました。

Bob Martinからの定義 ： ソフトウェアエンティティ（クラス、モジュール、関数など）は拡張のために開かれている必要がありますが、変更のために閉じられている必要があります。

したがって、モジュールには2つの主要な特性があります。

• それらは拡張に対して開かれています。 これは、モジュールの動作を拡張できることを意味します。 アプリケーションの要件が変わると、変化する要件を満たす新しい動作をモジュールに追加します。 つまり、モジュール関数の構成を変更できます。
  
• 変更のため閉鎖されています。 モジュールの動作の拡張は、モジュールのソースコードまたはバイナリコードの変更に関連付けられていません。 構成可能なライブラリ、DLL、またはEXEファイルであっても、モジュールのバイナリ実行可能表現は変更されません。

Bertrand Meyerからの定義 ： モジュールはオープンとクローズの両方が可能でなければなりません。
さらに、 オープンネスとクローズネスの概念は次のように定義されています。

• モジュールは、まだ拡張可能な場合、 オープンと呼ばれます。 たとえば、多くの操作を展開したり、データ構造にフィールドを追加したりできます。
  
• モジュールは 、他のモジュールで使用できる場合、 プライベートと呼ばれます。 これは、モジュール（情報隠蔽の観点からのインターフェース）に、厳密に定義された最終記述がすでにあることを意味します。 実装レベルでは、モジュールのクローズ状態は、モジュールをコンパイルし、ライブラリに保存し、他のモジュール（そのクライアント）が使用できるようにすることを意味します。

言い換えると、Meyerはモジュールのオープン/クローズドインターフェイスについて語り、Martinはインターフェースと実装を含むモジュール全体をオープン/クローズドします。

再コンパイルせずにモジュールの動作を拡張する可能性は、モジュールの要件に記載する必要があり、原則に基づくものではありません。

同時に、Open-Closed原則の例として、 Drawメソッドを備えたShapeクラスがまだ与えられていることは面白いです。これは、構造設計のソリューションと比較して、Open-Closed原則に対応しています。 しかし同時に、新しいタイプのFigureまたは新しい操作を基本クラスShapeに追加する場合、このソリューションを展開用に開いて変更用に閉じる方法については沈黙しています。

ISP

本を読んでいる間、私は本がゼロから書かれたのではなく、第2版であり、その例がC＃に翻訳されていると繰り返し思いました。 さらに、この本は「額に沿って」やり直されており、.NETプラットフォームのイディオムを使用して処理されません。

このプロパティの最も優れた表現の1つは、インターフェイス分離の原則の説明に記載されている例です。

インターフェイスの分離の原理は、2つの例で検討されます。1つは、 Door （Door）のクラスとTimedDoorのサブクラスを持つセキュリティシステムで、ドアがしばらく閉じられない場合に可聴信号を発するものです。 この問題を解決するためのオプションの1つは、「委任による分離」セクションで説明されており、著者によれば、ISPを満たします。



著者はこれについて次のように書いています。 「このソリューションはISPの原則と一致しており、DoorクライアントとTimerクラスの間に接続を作成しません。 ...しかし、それはあまりにもエレガントではありません。 タイムアウトを登録するたびに、新しいオブジェクトを作成する必要があります。

このセクションを読んだ後、私は若いマーティン（.NETの息子）がそれを読んだ後に言うべきことを想像しました。

「Pa、聞いてください、このデザインオプションは最新のものではないことを理解しています。あなたと私は一から本を書いているわけではありませんが、それでも...
結局のところ、2つの余分なクラスがありますが、 timeoutIdを受け入れるTimedDoorクラスのDoorTimeoutメソッドについては、トリックがまったく引き裂かれます！ 結局のところ、.NETには最初からタイマーがあり、それらの「オブザーバー」は、インターフェイスではなくイベントに基づいて構築されます。 したがって、 TimerClientとDoorTimerAdapterを破棄し 、 DoorTimeoutメソッドを閉じることができます（さらに、このtimeoutIdを破棄することもできます）。
したがって、設計の観点からは、コードはよりクリーンになり、実装の観点からも同様になります。 したがって、この例を捨てて、C＃のイディオムのために章を完全に処理する必要があります。そうしないと、コミュニティはそのような創造性を認めないかもしれません！

しかし、明らかにそのような会話はありませんでした！ したがって、この章では、通常のC＃アプリケーションでは見つけることができない非常に悪い例を示します。

UML

「静的ダイアグラムは、プログラムの不変の論理構造、つまり要素、つまりクラス、 オブジェクト 、データ構造、およびそれらの間の関係を記述します。」

オブジェクトは「プログラムの不変の論理構造」の一部ではありません。

「関連付けは単純な関係であり、あるオブジェクトが別のオブジェクトへのリンクを保持し、別のオブジェクトのメソッドを呼び出すという事実から成ります。」

関連付けは、リンクの保存を意味するものではありません。 クラスAがシングルトンを直接使用する場合、リンクはありませんが、関連付けがあります。

「構成は、集計の特殊なケースです。 繰り返しますが、実装は一般的な関連付けと区別できないことに注意してください。 今回は、この関係はC ＃ プログラムでほとんど使用されないためです。

ここで、制御言語では、全体がコンポーネントの寿命を厳密に制御している場合、純粋な構成を達成することは不可能であると言わなければなりません。 しかし、論理的な観点から話すと、開発者が依存関係の逆転の原則を乱用しない場合、C＃での合成が非常に頻繁に使用されます。

パターン

本が原則とパターンを説明しているのは非常に興味深いですが、一部の説明は他の説明にほとんど依存しません。 したがって、DIPパターンで説明されている問題の多くは、オブザーバー、戦略、およびメディエーターによって正常に解決されていますが、この原則を説明する際にパターンは実際には言及されていません。 または、 Singletonの問題を説明するとき、すべてのユーザーがDIPに違反し、テスト容易性に問題があると言わなければなりませんが、これらの類似点は描かれていません。
今、少し特異性。

ファサードとメディエーター

「この章で説明するパターンには、1つの目標があります。オブジェクトのグループに何らかのポリシーを課すことです。 ファサードは上からポリシーを課し、メディエーターは下からポリシーを課します。 ファサードは表示され、制限が課されます。メディエーターは表示されず、何も制限しません。

トロール80左レベル！ したがって、2つの概念の間に共通の基盤を見つけることができ、それらが存在しない場合でも、それらの違いのおかげでそれらを1か所にまとめることができます！

これらのパターンには実際には共通点はなく、さまざまなカテゴリー（ファサード-構造、メディエーター-行動）に属し、さまざまな抽象化レベルでさまざまな問題を解決するように設計されています。 本の章は、クラスやモジュールと同じくらいまとまりがあるべきであり、1つの場所で異種の概念を説明しようとする試みは疑わしいようです。

デコレータ

「データベースを操作するためにデコレータを使用する方法は2つあります。 読み取りおよび書き込みのメソッドを追加してビジネスオブジェクトを装飾したり、ビジネスルールを提供して、自身の読み取りおよび書き込み方法を既に知っているデータオブジェクトを装飾することができます。 後者のアプローチは、オブジェクト指向データベースを操作するときによく使用されます。

WTF？！ デコレータの本質は、装飾されたオブジェクトのインターフェイスを変更せずに動作を変更できることです。 「読み取りおよび書き込みメソッドでそれを補充」し、単一の仮想メソッドを再定義しない場合、結果のクラスは適切なデコレーターになりません！

はい、正式には、デコレーターを使用して操作を追加できますが、基本的に新しい操作を追加するのではなく、既存のクラスの機能を拡張する必要があります。 それでも、デコレータは「顧客の責任をオブジェクトに動的に動的に追加するために」使用されます。

訪問者

「この依存サイクルは、訪問したすべてのサブクラス（すべてのモデムタイプ）をリンクするため、訪問者を段階的にコンパイルしたり、訪問した階層に新しいサブクラスを追加したりすることは困難です。」

明らかに、選択されたフラグメントは、C ++からC＃への移行後に更新されていません。
「さらに悪いことに、キャスト速度は階層の幅と深さに依存する可能性があるため、予測が困難です。」

実装の多重継承がある環境では、大きな階層がキャストのパフォーマンスに影響を与える可能性がありますが、.NETのこれらの単語の証拠を見つけることができませんでした。

状態

第36章では、単純なベクトル（ IList型のフィールド）に基づいて作成された変換テーブルについて説明します 。これにより、次のアドバイスが得られます。

「このソリューションの欠点は、主に生産性が低いことです。 変換テーブルでの検索には時間がかかります。 ステートマシンが非常に大きい場合、検索時間が顕著になる可能性があります。
遷移表に基づく状態パターンは、開発コスト/効率の点で最も成功したソリューションの1つであると常に考えていました。 しかし、もちろん、典型的な解決策は、O（1）遷移検索の複雑さを提供する辞書の使用を伴います。

テンプレートの方法と戦略

「パターンテンプレートメソッドは実際には使いやすいですが、十分な柔軟性がありません。 Strategyパターンには必要な柔軟性がありますが、追加のクラスを導入し、追加のオブジェクトを作成してシステムに組み込む必要があります。したがって、これらのパターンの選択は、Strategyの柔軟性が必要か、Templateメソッドのシンプルさを楽しむ準備ができているかによって異なります。

パターンの柔軟性の欠如テンプレート方式は欠点ではなく、機能です。 相続人による便利な拡張のためのクラスの開発は単純なタスクではないため、基本クラスは、相続人が押し込まなければならないフレームワークを提供できます。

単体テスト

ボブ・マーティンはTDDの有名な支持者ですが、契約の観点からデザインについて考えることを好みます。 その結果、実装は前提条件や事後条件ではなくテストによって「駆動」されたため、本のコードにはいくつかのバグがあります。 詳細については、記事「契約、ステータス、ユニットテスト」を参照してください 。

Martin単体テストにはいくつかの問題があります。 まず、膨大な数のテストがデータベースに送られるため、本質的に統合テストになります。 2006年に2つの概念に明確な分離があったかどうかはわかりませんが、現在、これらの概念の違いは多かれ少なかれ明らかです。

フォールンユニットテストとは、コードのバグ、または少なくとも意図した動作と実際の動作の不一致を意味します。 統合テストの失敗は、環境問題に起因する可能性があるため、何も意味しません。 ユニットテストがビルドに落ちてすべてのビルドで実行され、統合テストは別のアセンブリで実行され、それほど頻繁に実行されないのはそのためです。

第二に、マーティンは原則に従って書かれたテストが多すぎることを引用しています：すべてのクラスの割り当てられたインターフェース、テストの作成、幸福。 このアプローチは、数か月間この方法で作業した後、カバレッジは良好ですが、デザインが悪いコードを取得することを気にします。

もちろん、次のように言うことができます。「まあ、それはまだ本の第2版であり、初版のオリジナルは2002年にすでに出ていたので、すべてが異なっていました！」 しかし、2006年に第2版が発行され、著者は得られた経験に基づいて本の内容を更新する時間がありました。 しかし、それはポイントでもありません。 初版（より正確には1年後）のリリース中に、エバンスは書籍「Domain-Driven Design」を出版しました。これは、設計、テスト、複雑さや他の多くの問題との戦いに関するより実用的な見解を示しています。 Evansは、不変性の利点、ロジックを単純なオブジェクト（値オブジェクトと呼ばれる）に転送することについての考えを既に見ています。ほとんどの場合、複雑な複合オブジェクトがそのような高レベルのメディエーターになるように設計を変えることができます。

その結果、すでに最初の段階で、「インターフェイスとテストを強調する」代わりに、別のアプローチが存在することがわかっていました。動作を、他のクラスにも外部環境にも依存しないクラスに分離します。 次に、実績のある低レベルクラスに基づいて構築される高レベルクラスを作成します。 その結果、実行時に動作を置き換える機能がアプリケーションで必要な場合にのみインターフェイスが強調表示される、強固な基盤上に構築された階層システムが得られます。

注
これについては、 「テスト済みデザインvs. 良いデザイン 。 」

興味深いことに、同じトピックで、契約対 ユニットテストでは、MartinとKoplienをフィーチャーした興味深いInfoQビデオがあります： CoplienとMartin Debate TDD、CDD、およびプロフェッショナリズム

ひどいテストの良い例

まあ、本はあなたがキーボードを選択する必要があるテストの例を提供します。 それらの1つを次に示します。

[Test] public void LoadingEmployeeDataCommand() { operation = new LoadEmployeeOperation(123, null); SqlCommand command = operation.LoadEmployeeCommand; Assert.AreEqual("select * from Employee " + "where EmpId=@EmpId", command.CommandText); Assert.AreEqual(123, command.Parameters["@EmpId"].Value); } 

このテストは何もチェックしません。合格した場合、テストとクラスのコードは同じであることを意味しますが、操作が正しく実装されているとは言いません。 それでも、テストはテストされたコードと比較してより抽象的である必要があります。そうでない場合、それらは役に立たなくなります。

.NET

本を読んでいるとき、これは本の第2版であり、C＃言語にわずかに適合しているが、新しいプログラミング言語のイディオムを使用して完全に処理されていないように感じます。 多くの場所で、Java命名のイディオムが使用され（小文字のメソッド名CONSTANTS_WRITE_THE_ SOK）、 Mainメソッドがドメインオブジェクトに追加され、アセンブリの代わりに「パッケージ」の概念が使用される場合があります。 例には標準の.NETイディオムがありません。オブザーバーでは、インターフェイスが使用され、イベントは使用されません。 readonly修飾子は使用されません。リソースを持つクラスはIDisposableなどを実装しません。 一般化は使用されませんが、本が登場する1年前に登場しました。

最も重大な間違いの1つは、次のサイドバー「どこに行きましたか？」に記載されています。
「一般的に言えば、特にこの概念が変わる可能性がある場合は、それに直交する特定の概念を名前に含めるべきではありません。 たとえば、 ICommandをインターフェイスではなく抽象クラスにしたい場合はどうでしょうか？ ICommandへのすべての参照を検索し、それらをCommandに置き換えますか？ この変更の影響を受けるすべてのアセンブリを再コンパイルして展開しますか？ 」

私見、 あなたのイディオムで別の言語に来るよりも、あなた自身のチャーターで外国の修道院に来る方が簡単です。 Javaでプログラムする場合、自分の好みに関係なくローカルの命名法を使用します。これは正しいです！ しかし、このサイドバーの何よりも、私は議論が好きです。

若いマーティンは、エンティティの名前を変更するかどうかに関係なく、インターフェイスから抽象クラスへの移行が潜在的な重大な変更であることを長老に伝えなかったようです。いずれにしても、「この変更の影響を受けるすべてのアセンブリを再コンパイルしてデプロイする」必要があります！ 同様の変更でオンザフライでアセンブリを交換しようとすると、アプリケーションがクラッシュします！

プライムジェネレーター

Martinsは状態が非常に好きであるため、素数ジェネレータ（p。80）をリファクタリングするときに、静的フィールドが割り当てられました。

「3つの関数の割り当てにより、いくつかのローカル変数をクラスの静的フィールドに変換できました。 その結果、どの変数が実際にローカルであり、どの変数がより広いスコープを持っているかがより明確になりました。

 class PrimeGenerator { private static bool[] crossedOut; private static int[] result; public static int[] GeneratePrimeNumbers(int maxValue) { return null; } //    crossedOut private static void UncrossIntegersUpTo(int maxValue) { } //  result   crossedOut private static void PutUncrossedIntegersIntoResult() { } } 

私はフィールドで中間結果を維持することの愛を理解していません。 ローカル変数を非ローカル変数から分離する場合、メソッドの引数もこれに適しています。共有状態を使用する必要はありません。

共有状態はコードを複雑にし（呼び出しの順序が重要になります）、異なるスレッドから並行して素数を取得することも不可能になります。これは、静的クラスメンバーはスレッドセーフである必要があると述べているフレームワーク設計ガイドラインの一般に受け入れられている規則に違反しています。

コードが、この本のリリースの1年前に出てきたイテレータブロックを使用しないと言っているのではありません。

SocketServer

このコードは251ページで説明されており、本に付属の例には含まれていません。 ここに置きます 。

 public interface SocketService { void Serve(Socket s); } public class SocketServer { private TcpListener serverSocket = null; private Thread serverThread = null; private bool running = false; private SocketService itsService = null; private ArrayList threads = new ArrayList(); public SocketServer(int port, SocketService service) { itsService = service; IPAddress addr = IPAddress.Parse("127.0.0.1"); serverSocket = new TcpListener(addr, port); serverThread = new Thread(new ThreadStart(Server)); serverThread.Start(); } public void Close() { running = false; serverThread.Interrupt(); serverSocket.Stop(); serverThread.Join(); WaitForServiceThreads(); } private void Server() { serverSocket.Start(); running = true; while (running) { Socket s = serverSocket.AcceptSocket(); StartServiceThread(s); } } //   } 

コードには2つのタイプの問題があります：第1に、これらは、読み取り専用の欠如、 IDisposableインターフェイスの欠如、オブザーバーを実装するためのイベントの代わりのインターフェイスの使用、非同期操作が.NET Frameworkの最初のバージョンから利用可能な場合のフローの手動操作、および例外処理の欠如などの些細な問題です。

しかし、最も重要なことは、このコードは設計が不十分な例です。 SocketServer 、 ServiceRunner、およびSocketServiceクラスの役割は あいまいで わかり にくいです。

たとえば、 SocketServiceインターフェースを実装するクラスがあります。 Serve （Socket s ）メソッドで何ができますか？ どういうわけか、彼はこのメソッドが別のスレッドで呼び出されると言っていますか？ いや しかし、親ソケットが閉じていることと、操作を中断する必要があることをどのようにして知るのでしょうか？ しかし、このメソッドでReceiveタイプのブロッキングメソッドを呼び出すことが可能かどうか、または独自の無限ループをねじる必要があるかどうかをどのように理解するのでしょうか？

コードのテストを書くことが不可能な場合、結果として生じるマーティンの設計はひどいものになることがわかります。 このコードは、.NET Frameworkの組み込み機能を効果的に使用していませんが、面白いのは、機能しないことです！ Closeメソッドを見て、 runningが そこでfalseに 設定され、それからthread .Interrupt （）が呼び出されますが、現在のサーバースレッドはserverSocket .AcceptSocket （）メソッドで新しい接続を待ってハングしているため、何にもつながりません。 同様の問題は、 Serverメソッドでs .Receive （）を呼び出す場合、すべてのクライアントソケットで発生します 。このhoroshkaはすべて閉じることができません。

ツリーマップ

ここでコード全体を見ることができます 。

 internal class TreeMapNode { private static readonly int LESS = 0; private static readonly int GREATER = 1; private IComparable key; private object value; private TreeMapNode[] nodes = new TreeMapNode[2]; private int SelectSubNode(IComparable key) { return (key.CompareTo(this.key) < 0) ? LESS : GREATER; } } 

ここではすべてがそれほど致命的ではありませんが、javaスタイルの定数の使用、 キーおよびノードフィールドのreadonlyキーワードの不在、ならびに失敗した定数名： LESSおよびGREATERは 、実際にはサブツリーのインデックスを決定します。

おわりに

この本をgoodreads.comで2点で評価した理由を尋ねられました。 さて、この場合、私は反対の質問を持っています：それは本当にもっと価値があるのですか？

この本はほとんど古典的なものであることが非常に怖いです。しかし、この本には、従うべき時とそうでないときについての疑わしいルールを含む疑わしい原則が含まれています。 この本には、パターンの漠然とした説明がありますが、これは前述の原則とはまったく関係ありません。 この本には、壊れやすいテストと、クラスの設計が少なくとも少し前に考えられていた場合には発生しなかったエラーを伴うコードを使用してルールをテストする2つのバケツが含まれています。 この本はC＃プログラマーを対象としていますが、2006年の標準でさえ、その中のコードは価値がありません。

この本は、経験の浅い開発者が読んだ場合、貨物のカルトの深刻な症状につながる可能性があり、経験のある開発者には何も与えないのではないかと心配しています。 したがって、この本の主な利点は、SOLID-ahや他の原則についてのトローリングに適切に参加できることですが、それ以上のことはないということがわかります。