パターンの利点

今後の投稿でパターンについて書く前に、まず 1 つの質問に答えなければなりません。パターンの利点は何ですか？ご想像のとおり、私には多くの利点がありますが、それらを 3 つのポイントに要約します:明確に定義された用語、改善されたドキュメント、および最高のものから学ぶことです。

デザインパターンについての最初の講演を行いました。これは 2002 年から 2008 年頃のことです。なぜですか？ パターンは、現代のソフトウェア開発においておそらく最も価値があり、影響力のある抽象化です。

では、大事なことを書かせてください。

パターンの利点

私の議論は 3 つの事実に基づいています:明確に定義された用語、改善されたドキュメント、最高のものから学ぶことです。

明確に定義された用語

パターンは明確に定義された用語を確立します。想像してみてください、私は走りに行き、驚くべき動物を見たとあなたに説明します。下手な英語で説明します。その動物は猫のような大きさで、毛皮と長い耳を持っていました。後ろ足が異常に長かった。したがって、3 メートル先、2 メートルの高さまでジャンプできます。走っている間、それは素早く方向を変えることができます。私が見た動物は、ヨーロッパのノウサギだと思います。正確な用語を使用すると、非常に役立ちます。これで用語がわかり、ウィキペディアで調べることができます。これが私にとってパターンの主な利点です。明確に定義された用語があります。何について話しているかはわかっています。

もっと具体的にしましょう。あなたはニュースリーダーを実装したいと考えており、私のアドバイスを求めています。何らかのニュースが発生した場合、ニュースリーダーの顧客に自動的に通知する必要があります。私の答えは非常に冗長で、ニュースリーダーには登録および登録解除機能が必要であることを説明できます。さらに、ニュースリーダーはすべての顧客を保存し、各顧客は通知メンバー機能をサポートする必要があります。ニュースリーダーが何かを発行すると、顧客リストを調べて電話をかけ、全員に通知します。それだけではありません。ニュースリーダーは、ニュースを送信することも、顧客が興味を持ちそうなニュースがあることだけを送信することもできます。アドバイスはこれで終わりではありませんが、ここでやめておきます。対照的に、私の答えは 1 つの用語である可能性があります:オブザーバーパターンです。詳細は文献で読むことができます。

ドキュメントの改善

ソフトウェアの詳細なドキュメントと高レベルのドキュメントを区別してみましょう.

詳細なドキュメント

正直なところ、私は次のような詳細なソースコードドキュメントは好きではありません:

// initialize a vector of strings
std::vector<std::string> myStrVec = {"12345", "123456", "1234", "1", "12", "123", "12345"};

// sort the vector of strings based on their length ascending
std::sort(myStrVec.begin(), myStrVec.end(), lessLength);

それどころか、コードは表現力豊かで散文のように読める必要があります:

std::vector<std::string> myStrVec = {"12345", "123456", "1234", "1", "12", "123", "12345"};

std::sort(myStrVec.begin(), myStrVec.end(), [](const std::string& f, const std::string& s){return f.length() < s.length();});

コードは真実を語っており、定義上、常に最新です。

ソフトウェア開発者としての私のキャリアの中で、レガシーソフトウェアを維持し、改善しなければならないことが頻繁にありました。通常、このソフトウェアは非常に複雑で、理解するにはかなりの頭脳が必要でした。時々、私はソフトウェアさえ理解できませんでした。ご想像のとおり、ソースコード内にパズルのピースを組み立てるのに役立つドキュメントを見つけたことが、どれほどうれしかったことか。悲しいことに、ドキュメントが古くなっていることに後で気付き、間違った方向に頭脳を投資しました。振り出しに戻りました。きめ細かいソースコードドキュメントはすぐに古くなります。古いドキュメントはひどいものです。コードは自明である必要があります。

ハイレベルドキュメント

正直なところ、私はソフトウェアのハイレベルドキュメントの大ファンです。

たとえば、UML または SysML でソフトウェアのアーキテクチャを説明するグラフィックを提供し、ソフトウェアにリアクターパターンを適用するとします。原子炉パターンは建築パターンです。複数のクライアント要求を同時に受け入れ、異なるサービスプロバイダーに配信できるイベントドリブンアプリケーションを構築するための実証済みのソリューションについて説明します。全体像を把握したので、詳細を詳しく見ていきましょう:

リアクターパターンに関する文献を調べる
その影響について同僚と話し合う
ソフトウェアの原子炉パターンの重要なコンポーネントを特定します。ソフトウェアの一部となるには、リアクタ、イベントデマルチプレクサ、イベント、およびさまざまなイベントハンドラなどのコンポーネントが必要です。 handleEvents, registerHandler, removeHandler, select, のような名前を使用します。または getHandle.

さらに、リアクターパターンのさまざまな側面を実装するために、設計パターンが役立ちます。たとえば、特別なイベントが発生した場合、イベントハンドラに通知する必要があります。ここではオブザーバーパターンが正しい選択かもしれません。さらに、オブザーバーパターンを使用して課題を解決したことを文書化する必要があります。これは非常に貴重なハイレベルドキュメントです。