デザインパターンを考えます。

デザインパターンを考えます。

ウィキペディアで検索します。

ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。

引用先URL：https://ja.wikipedia.org/wiki/デザインパターン_(ソフトウェア)

初学者の自分にはつかみどころのない感じで理解が出来ませんでした。

なので自身が紐解いていく過程を書き残そうと思います。

デザインパターン初学者が"デザインパターン"を理解するための一つのパターンとなることを目標に頑張ります。

（かなり紆余曲折することや誤った解釈をする可能性があります。その際は是非コメントをお待ちしています。よろしくお願いします。）

でははじめます。

情報を増やします。

ウィキペディアで多言語版から「English」のリンクをクリックします。すると要約にしては長めの導入があります。

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for functional programming languages, some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

Design patterns may be viewed as a structured approach to computer programming intermediate between the levels of a programming paradigm and a concrete algorithm.

In a recent review study, Wedyan and Abufakher investigate design patterns and software quality and conclude: "Our study has shown that the primary studies provide an empirical evidence on the positive effect of documentation of designs pattern instances on program comprehension, and therefore, maintainability. While this result is not surprising, it has, however, two indications. First, developers should pay more effort to add such documentation, even if in the form of simple comments in the source code. Second, when comparing results of different studies, the effect of documentation has to be considered."

引用先URL：https://en.wikipedia.org/wiki/Software_design_pattern

情報が増えた気がします。英語をそのままスラスラと読めないので翻訳します。

ソフトウェア工学では、ソフトウェア設計パターンとは、ソフトウェア設計において、与えられたコンテキスト内で一般的に発生する問題に対して、再利用可能な一般的な解決策のことを指します。これは、ソースコードやマシンコードに直接変換できる完成したデザインではありません。むしろ、多くの異なる状況で使用できる問題を解決する方法の記述やテンプレートです。デザインパターンは、アプリケーションやシステムを設計する際に、プログラマーが一般的な問題を解決するために使用できる、形式化されたベストプラクティスです。

オブジェクト指向のデザインパターンは、通常、最終的なアプリケーションのクラスやオブジェクトを特定せずに、クラスやオブジェクト間の関係や相互作用を示します。変形可能な状態を暗示するパターンは、機能的なプログラミング言語には不向きかもしれませんし、解決しようとしている問題を解決するためのサポートが組み込まれている言語では、いくつかのパターンは不要になる可能性があります。

デザインパターンは、プログラミングパラダイムと具体的なアルゴリズムの間の中間的なコンピュータプログラミングの構造化されたアプローチと見ることができます。

最近のレビュー研究では、WedyanとAbufakherはデザインパターンとソフトウェアの品質を調査し、次のように結論づけています。"我々の研究では、設計パターンのインスタンスを文書化することがプログラムの理解度、ひいては保守性にプラスの効果をもたらすことを、一次研究が実証的に示しています。この結果は驚くべきものではありませんが、2つの示唆があります。第一に、開発者はソースコードに簡単なコメントの形であっても、そのような文書を追加するために、より多くの努力を払うべきであるということです。第二に、異なる研究の結果を比較する際には、ドキュメンテーションの効果を考慮しなければなりません。

翻訳をし修正せずに貼り付けました。色々とわかりました。

ソフトウェア設計パターンとは、ソフトウェア設計において、与えられたコンテキスト内で一般的に発生する問題に対して、再利用可能な一般的な解決策のことを指します。

一般的な解決策というのがノウハウということだと思います。

そして重要なのが

これは、ソースコードやマシンコードに直接変換できる完成したデザインではありません。むしろ、多くの異なる状況で使用できる問題を解決する方法の記述やテンプレートです。

ということですぐに使えるわけではないようです。このことからも初学者がまず学ぶには早いことが伺えます。しかし学ばないことにはいつまでも初学者だと自分は思いますので時間をかけてでも紐解きます。

デザインパターンは、アプリケーションやシステムを設計する際に、プログラマーが一般的な問題を解決するために使用できる、形式化されたベストプラクティスです。

"ベストプラクティス"はそのままカタカナになっていますのでbest practicesとして解釈して、最善の措置とします。

best practices：https://ejje.weblio.jp/content/best+practices

一般的な問題というのがどのような問題なのかは想像するしかないですが、基本自分が携わっているシステムは問題を解決するためにありその中に問題解決のアプローチのための機能があるという構成だと思っています。なので一般的な問題の解決の措置の形式化というのはとても心強くやはり紐解いていきたいと強く思います。

残りの説明は現在の私では読めるには読めるのですが、ここで記事にするための確固たる理解を持ち合わせていなかったので、割愛します。

ウィキペディア英語版によって、情報が増えました。同時にデザインパターンを使いこなすにはまだまだ思慮が浅いこともわかりました。

web検索をして、デザインパターンの解説記事をいくつか読みました。多くは仮の問題を解決しているシステムもしくは実際の問題を解決しているシステムに当てはめて、プログラミングコードと共に記述されていました。

そしてプログラムに関してソフトウェアに関して思慮の浅い自分がその記事を書くことは できるかもしれませんが 得策ではありません。既存もしくは想定のシステムを分解してデザインパターンを当てはめるには情報・知識があまりに足りていないからです。

しかし諦めが悪いので特に有名とされる本を購入しました。

オブジェクト指向における再利用のためのデザインパターン

まずは形から入るのが自分のスタイルです。サイズはB5判 厚さ約28mmあるこの本はものすごく勉強している感があります笑。

（小話です。小さなカフェでこの本を開いて読んでいたところ、後ろの方から「俺も資格の勉強が忙しかった時があったなあ」という声が聞こえてきた時がありました。）

デザインパターンは「ソースコードやマシンコードに直接変換できる完成したデザインでは」ないということでしたので、古いですがこの本を中心にパターンを紐解いていくのは問題はないと思いました。

本のタイトル：オブジェクト指向における再利用のためのデザインパターン

どんな本か

オブジェクト指向設計の入門書ではない。

近くの解説書に手を伸ばすようなことはだめである。

（序文から見捨てられてしまった感が…）

本書は、オブジェクト指向ソフトウェア設計において遭遇するさまざまな問題に対して、簡単でかつ明瞭な解を与えるデザインパターンの本である。本書中のデザインパターンは、これまでに時間をかけて徐々に改良されてきた解法を、体系的に表したものである。

デザインパターンを理解するメリット

設計プロダクトの柔軟性、モジュール性、再利用性、および理解のしやすさをより高めるためにはどうすればよいかがわかるだろう

自分へのお助けメッセージ

1回読んだだけでこの本を完全に理解できなくても気にすることはない。ー中略ー本書は、１回読んでその後本棚にしまっておくような本ではないことを覚えておいてほしい。

デザインパターンという考え方は古くからあった。

複雑なシステムをうまく扱うためにはパターンが重要であることは、他の学問においては古くから認識されてきた。特にChristopher Alexanderは、建築物や街を構築するためにパターン言語を用いる考え方をおそらく初めて提案した人物である。

「まだオブジェクト指向設計でそれほど経験を積んでいない」人向けの読み方で紐解く

（かなり自分向けの読み方があったのでこの方法で進めます。）

「大きなシステムの場合は、」下記「のパターンをほとんどすべて用いている。」

・Abstract Factory パターン
・Factory Method パターン
・Adapter パターン
・Composite パターン
・Decorator パターン
・Observer パターン
・Strategy パターン
・Template Method パターン

この本のおすすめの８パターンを学んでいこうと思います。（この部分を読んでいる時は　あれ？意外と少ないじゃん　と思っていました。現在Abstract Factoryの理解が簡単なようでいざ記事にするとなるときついという状況に陥っています。この８パターンを書き進めることはできるのか…）

オブジェクト指向における再利用のためのデザインパターンは、"Gang of Four" "GoF"の愛称で有名なGamma Erich、 Helm Richard、 Johnson Ralph、 Vlissides Johnの４名の著者による本です。「4つの国を渡り歩」いた本書は４名に留まらず、草稿を多くの方々が読んでおり、加えてインターネットなどを通して多くの方々がデザインパターンについてコメントをして出来上がっています。そして「1994年の5月に行った講義では」60人以上の方々からフィードバックを受けそれが適用されています。

まさにデザインパターンと言ったらこれ！というくらい長い時間と多くの人々が関わっています。有り難さともに著者を含めた多くの人々が研磨したデザインパターンを読み解きたいと思います。

次回はAbstract Factory パターンです。