私の尊敬されている開発者をサポートするために（海外に引っ越しているにもかかわらず、セルゲイ自身は私たちのことを考慮しています-証拠のために彼のブログにアクセスしてください） その前に、私は4つのギャングとDesign Patterns Head Firstを読んだので、原則として、比較するものは何もありません。
この本は300ページ強を必要とし、1週間のゆったりとした読書で簡単に習得できます。 本は4つの部分に分かれています。
- 行動パターン
- 生成パターン
- 構造パターン
- 設計原則
パターンをそのようなグループに分割することは、長い間確立され、定着しました。 4人のギャングとは対照的に、Sergeiの本には、SOLID設計原則に関する章があります（実際、これらの4つの原則のギャングの本は、私たちが慣れ親しんでおり、後で策定されたためにできませんでした）。 4つのギャングの本には、テキストエディターの開発を例にパターンを説明する実用的な章があります。 テキスト全体で、Sergeyはログ処理アプリケーションの開発時に発生する問題を使用します（私が理解しているように、このトピックはMicrosoftでSergeyが現在行っていることとほぼ同じです）。 4人のギャングの場合のように、個別の実用的な章はありません。 原則として、著者はこの例を使用してパターンを分類するのが得意ですが、すべてがあまりにも簡単に与えられていることに注意してください。つまり、物語の過程で特別な問題はありません-すべてが時計仕掛けのようになります。 ほとんどの場合、これは執筆時点で意図されていましたが、どこにも挑戦がないことは非常に楽しいとは思えませんでした（申し訳ありませんが、野barのため）。 私の意見では、テキストエディタを使用した例はより興味深いように見えます。 この本の短所のうち、もちろんこの発言を直接的に帰することはできません。
この本は、私が本を最初から最後まで読んだだけのまれなケースです。 そして、この本は非常に簡単に読めることをお伝えしなければなりません。 もちろん、パターンに精通し始めたばかりの開発者は、本全体をそれほど気楽に読むことはできないでしょうが、初心者にとっては、この本よりも理解しやすい本を想像することはまだ難しいと思います。 パターンのより深い理解は、著者が選択したプレゼンテーションのスタイルと形式によって促進されます。この本は、主に彼自身の経験を反映したものであり、他の人の考えの退屈な編集ではなく、これは非常に印象的です。 例は、選択した種類のアプリケーションが本当に好きではなかったという事実にもかかわらず、依然として良好であり、彼らのタスクに対処できます。 非初心者の場合、自分の経験を著作権と比較することは興味深いかもしれません。 多くの場合、私は自分の考えの確認を見つけましたが、それについて議論する人はいませんでした。 したがって、個人的には、本を読む過程で、著者との内部対話が絶えず行われました。
この本の対象読者については、.NETには多くの利点がありますが、パターンの形状に大きな影響を与える可能性のあるものはほとんどありません。 実行すると、.NETではインターフェイスの明示的な実装を行い、デリゲートを使用して一部のパターンを単純化できることを思い出すことができます。 確かに-多重継承はありません。たとえば、「死のダイヤモンド」は描かれているほど怖くないので、実際には、ボブ・マーティンは.NETチームのカントと考えていますが、多重継承は場合によっては非常に便利です（頻繁に言うことはありませんが）。 .NETプラットフォームにはそれほど多くの機能がないため、パターンに興味がある人は誰でも、命令の言語に関係なく本を読むことができます。
著者は、継承を頻繁に使用するパターンの古典的な図を提供しますが、パターンは古典的な形式ではめったに使用されないため、多くの場合、単純化されたオプションを提供します。 一般に、作者は、盲目的にパターンを使用してはならないことを示すことを忘れず、タスクと要件に合わせて脳をオンにすることを教えます。 また、ユニットテストの作成と組み合わせて、パターンの使用を検討することが重要であることにも注意してください。
セルゲイが本を書いていると発表したトピックでは、「パターンはゴミであり、人々は数えられ、そしてメガファサードと別の100,500パターンの工場の工場を必要としないところに作ります」と言うことを怠らない人々がいました、パターンに関するこれらすべての本、これらすべてのパターンはすでに理解可能である理由。」 私の謙虚な意見では、これらの人々のほとんどは、読み込めない技術不足のgovnokodを書き、それはその後千回書き換えられます。 今がその時です。 第二に、はい、パターンの軽率な使用は悪いですし、良い本にも書かれています。 プログラミングは工学であり、工学では、特効薬やすべての質問に対する普遍的な答えはありません。 したがって、優れたプログラマーは、問題を解決するために、常に自分が危険にさらされているものと、複雑な祭壇にもたらす準備ができているものを常に評価します。 残念なことに、そのような芸術を教える本はありません（誰もが見たなら、それを共有してください）。実際のタスクに関する長年のハードトレーニングの助けを借りて、ソリューションの複雑さ、シンプルさ、力のバランスを取る方法しか理解できないからです。
私は本の中で、すべての原則に従うことは（正確で良いフォローであっても）シックなアプリのデザインを保証するものではないというアイデアが好きでした。 それはすべて、タスク、最終的にはOOPがそのようなタスクにどのように当てはまるかによって異なります。
次の古典的なパターンは本では考慮されていません： "bridge"、 "flyweight"、 "memento"、 "prototype"。
プロトタイプパターンはかなり鈍く、ひどいICloneableを介して実装されます（このコピーが深いか表面的かを理解することはできません）が、もちろん実装は改善できます。 たぶんそれがこのパターンが本から除外された理由です。 残りのパターンは非常に興味深いものであり、それらが考慮から除外された理由はわかりません。 また、MVC、MVP、MVVMなど、すべての種類の「複合」パターンについても説明していません。 むしろ、彼らはつかの間の影響を受けますが、著者はそれらを掘り下げません。そして、私は、彼らがそれぞれ別々の本に専念できるので、これは正しいと思います。
私が著者に完全に同意していない数少ない点の1つは、継承者が宣言されていない例外をスローする瞬間です。これらの例外が基本クラスコントラクトで指定されていないか、対応するセクションのXMLコメントで指定されていない場合 可能性のある例外を示すために、それらを契約で宣言すること（契約は使用しませんでしたが、可能性のある種類の例外を宣言できることは本からわかりました）は悪い習慣ではありませんが、宣言された例外のみが飛ぶ。 たとえば、ファイルシステムに忍び込み、あらゆる種類の可能な例外を宣言するメソッドをBCLでいくつ見ましたか？ そうです、そのような方法はありません。 .NET開発者は、最初にチェック例外の概念を放棄しました。 例外を介したエラー処理システムは、安定したアプリケーションを開発したい人にとってはまだ大きくてfatです。 例外を介したエラー処理を正しく行うには、アーキテクチャの適切な構築、例外の種類の適切な選択、テストの適切な作成、契約など、多くのことが必要です。 開発チームがこれらの領域の少なくとも1つで問題を抱えている場合、アプリケーションはenましい規則性で、多くの場合、作業を続行できる「無害な例外」によってクラッシュします。
結論として、素晴らしい本を書いてくれたセルゲイに感謝します。もっと書いてください！ 10点満点で、この本を8-8.5と評価します。