デザインパターンを抑制する

何年も前、私は経済学の教授と、デザインパターン、プログラマー向けの共通言語の確立方法、よく知られている問題をうまく解決する方法などについて話していました。

それから彼は、これは彼が経済学の学生に使用するのとまったく反対のアプローチであると私に話しました。彼は通常問題を提示し、最初に解決策を見つけるように依頼したので、彼らは最初にそれについて考え、最初に問題を解決する方法を見つけようと試みました。

だから私は、「デザインパターン」アプローチが本当にプログラマーを賢くするのか、または愚かなものにするのかと考えていました。新しい革新的な方法。

どう思いますか？

あなたの経済学教授は絶対に正しいです。

ソフトウェア設計パターンは、主に経験豊富なソフトウェア開発者が互いに通信する方法です。これらは、既知の問題に対する確立された解決策の略です。

ただし、パターンなしで問題を解決する方法を理解している、または同様のパターンを独自に思いついた人だけが使用する必要があります。そうしないと、コピー/貼り付けコーダーと同じ問題が発生します。彼らはコードを持っていますが、彼らはそれがどのように機能するか理解していないので、それをトラブルシューティングすることができません。

また、設計パターンの多くは、大規模な企業ソフトウェアシステムで使用することを目的としたエンタープライズパターンです。 Inversion of Controlコンテナの素晴らしさを学ぶなら、ほとんどのプログラムが実際にそれを必要としないとしても、あなたが書くすべてのプログラムでそれを使用したいでしょう（小さなプログラムに依存関係を注入するより良い方法がありますIoCコンテナは必要ありません）。

パターンを学びます。パターンとその適切な使用方法を理解してください。パターンなしで同じ問題を解決する方法を知ってください（すべてのソフトウェアパターンは基本的なアルゴリズムの抽象化です）。そうすることで、理にかなっているときに、自信を持ってソフトウェアパターンを使用できるようになります。

デザインパターンの人々にデザインパターンを見てもらいたい方法は、同様の問題が発生した場合に適用できるソリューションのセットです。彼らは、山の上に石板に刻まれたモーセに神から与えられた唯一の可能な解決策としてそれらを考えてほしくありません。

残念なことに、一部の人々は、それらを学ぶことができるたくさんのサンプルデザインよりも、聖典に近いものと考えています。それは創造性を殺し、カーゴカルトを設定します。

あなたの経済学の教授は、学生に問題を提示し、彼らに最初にそれを解決しようとすることを言及しました。頭の中でさまざまな問題の解決策をたくさん持っているのは良いことであり、それはDesign Patternsが目指していることです。いくつかの点で失敗すると思います（シングルトンが悪いアプローチを奨励し、命令型オブジェクト指向に近視を集中させるなど）。ただし、ソフトウェアのすべての可能なソリューション例は公式の設計パターンでなければならない、と考えるのは間違いです。

問題を見て、「これの設計パターンとは何ですか？」

問題を見て「これをどのように解決できますか？」と自問すると、非パターンソリューションがある場合はそれが表示され、適合するパターンがある場合はそれも表示されます。

また、あなたの経済学教授は正しいと思います。それはそもそも何かを学ぶ方法です。しかし、次のように見てみましょう：創造性のために、ホイールを秘密にしてみんなに再発明させてくれませんか？すべての人が車輪を発明できる/作れないというわけではないので、私はあなたが「いいえ」と言うことを期待します。ありません。

プログラマーに戻りましょう。私は毎日Web開発者なので、MVCは日常的にやり取りするものの1つです。何度か自分の構造を構築しようとして、多くのことを学びましたが、それらはすべて基本的に失敗しました。最善を尽くしましたが、MVCがない場合はどうなりますか？信頼性、保守性、拡張性の点で、ソースコードは単純です。

それは私たちのほとんどにとって同じだと思います。DIについて誰もあなたに話さない場合-良い習慣として、開発者がレッスンを学ぶまで、いくつのエンタープライズアプリケーションが苦労するか失敗するでしょうか？

2番目のポイントは、業界標準です。MVCをWeb開発者に教えないのであれば、最初に物事のやり方を学ぶために時間を費やす必要がある非標準の構造のすべてに直面する準備はできていますか？良いアイデアを持っていますが、それらのほとんどは、あなたのソフトウェアプロジェクトに深刻な結果をもたらすかもしれない深刻な設計上の欠陥を持っています-よく知られているフレームワークでさえ、時々設計上の欠陥と苦労しています。

しかし、これらのすてきなアイデアをすべてまとめてまとめ、それらの賢い開発者がそれらすべての実験から良いことを取り入れて、その特定の問題に最適な本当にクールな構造を作成したらどうなるでしょうか？次に、デザインパターンを作成しました。あなたが生き物なら、他に方法はありません。動物でさえ、日々の生活の中でベストプラクティスとデザインパターンに従います。

ハンマーを再発明しないでください。しかし、すべての問題を釘のように扱ってはいけません。

プログラミングパターンは、すぐに忘れられる可能性のある平均的なケースですぐに使用できるソリューション、優れたドキュメント化、テストを提供するため、時間を大幅に節約できます。ただし、いつ使用するかを学習する（そして考える）必要があります。

あなたの質問を言い換えます：運転することを学ぶことは私をより速く動かすか、単にゆっくり歩くか

プログラミングパターンの使用方法を学習することは、独自のソリューションを見つけることを行使すべきではないという意味ではありません。あなたの創造性を発揮するのに十分な問題がまだあります。プログラミングパターンを知ることは、よく知られた問題をすばやく把握し、それほど重要ではない問題に集中することだけを可能にします。

質問の2番目の部分に戻ります-あなたの教授は正しいですか？

はい、彼は正しいです。研究の主な目標は学生に考えることを学ぶことです。問題に対する独自の解決策を見つけ、既存の解決策に直面する必要があります。その方法でのみ、彼らは本当に彼らを理解することができます。最初にパターンを学習する場合、背後にあるものを理解するのではなく、それらを適用するために機械的にのみ学習する危険があります。

これが最初に学生にプログラムを教える理由であり、パターンはさらに学期に導入されます。

デザインパターンを教えることで、プログラミングを教えることは絶対に避けたいと思います。それらの背後にある原則を理解せずにそれらをうまく適用することはできないので、それらの原則を教えることははるかに重要です。

とにかく、デザインパターンは実際に働くプログラマにとってそれほど価値があるとは思わない傾向があります。与えられた設計パターンに含まれる原則を完全に理解していれば、それが良い解決策である状況では、たとえ知らなかったとしても、当然、とにかくそれを構築する傾向があります名前のあるパターンであったこと。パターンの学習に費やす時間はいつでも、一般的なコードについての考え方を学ぶのに費やす方が良いでしょう。「一般的な問題解決」のスキルがゼロでない場合、パターンのセットをどれだけうまく適用しても、良いコードを書くことはできません。また、「一般的な問題解決」スキルが優れている場合、単一のパターンを知らなくても問題を解決できます。

また、パターンと呼ばれるほど一般的なアイデアはすべてライブラリに適切に実装されており、コードを絶えず書き換えるのではなく実際に再利用するため、理想的な世界ではデザインパターンは存在しないと思います。「正規表現デザインパターン」があった場合、それを使用するたびに小さな正規表現エンジンを実装する必要があったと想像してください。デザインパターンは、言語が適切な抽象化機能を提供しないため、記述できない単なるライブラリです。

それは実際、それらをあまり気にしないもう一つの理由です。それらは時々主張されているほど普遍的ではありませんが、実際には特定の言語が許可/奨励するプログラムを構築する特定の方法に非常に強く結びついています。Python用に書かれたデザインパターンの本は、Java用に書かれたものとはまったく異なり、Haskellのような非命令型言語用に書かれたものとはさらに異なります。より深いレベルで理解することをお勧めします。また、慣れ親しんだ言語でデザインパターンを自分で発見できるようになります。

商業と教育には異なる目標があります。学生にデザインパターンを教える場合、同じアプローチを取ります。しかし、実稼働環境では、時間と効率がすべてです。

さらに、教室外の（マクロ）経済学は別のものです。政府が「おっと！今、私たちは税金をやるのと同じように非常に退屈しているので、今回は超奇抜な何かを試してみましょう」と言っているのを見ますか？いいえ、そのような野生の実験は修復を超えて経済を粉砕する可能性があるため、そうではありません。代わりに、彼らは試行錯誤のアプローチに固執する傾向があります：金利を上げる、税の休日を発表する、など。言い換えれば、彼らはデザインパターンに依存しています。

もちろん、答えは「はい」です。

デザインパターンは、それがどのように機能し、なぜ彼らがもたらす価値をもたらすのかを理解するのに時間がかかる限り、それ自体素晴らしい学習ツールです。

また、常に発生する問題に対する馴染みのあるソリューションを提供するため、設計プロセスを迅速に追跡することにより、生産性を大幅に高めることができます。

ただし、設計の短絡が多すぎる場合、または人々がその使用について独断的で過度に正確になると、逆の効果があります。

設計パターンはもちろん、それほど創造的ではありません。それが全体のアイデアです。創造性は乏しい資源です。あなたは創造性を必要としない問題にそれを浪費すべきではありません。数百人の開発者と同じ方法で問題を解決すれば、はるかに簡単で迅速に動作しやすくなります。その仕事をする退屈でエキサイティングなコードは実際には良いです。