sinakuの備忘録: デザインパターン

どうにもUbuntuやWindows 8などを見ていて、最近プログラムに全く手を出せていない気がしないでもない。

ってことで久しぶりに頭の体操としてデザインパターンのお話を備忘録に残しておくことにする。

基本的にデザインパターンって何よって事だが、プログラムを実装するうえで起こりうるさまざまな問題点に対しての回答というのが簡単に理解できて短い説明だと思う。

たとえば拡張性がどうたらとかいった問題を解決する為の手法です。

色々本を読むと小難しく説明しているものもありますが、先人達が苦労したけど結果こうしたら上手くいったよってのをパターン化したものですんで、そんなに難しく考える事もないです(´ρ`)

紹介してあるデザインパターンの本についても目を通すとえらく小難しい事を書いてありますが、
意訳すると上のような感じです。

なんで気軽に考えて大丈夫です(´ρ`)

よくあるプログラムを作成するのに初心者の方々が、オブジェクト指向やデザインパターンや、MVVMなどの聞きなれないパターンを聞いて混乱する事がありますが、その辺の解決策になると良いなぁ～っと祈っております。

そもそも、オブジェクト指向などの説明も難しくしようとすれば難しく説明でき、非常にありがたく聞こえるが、内容を理解して意訳するとそんなにありがたいものでもない。

乱暴な言い方をすればオブジェクト指向はデータと関連するロジックをまとめて、蓋をして中身みえないようにして、なんかあったら外から叩いて中の様子が分かるようにしよう。
みたいなものである。

この辺ありがたがって、難しい言葉を並べると、初心者は難しいけど凄い事なんだと勘違いをして、手を出すのをためらってしまう。

なんで今回のデザインパターンについても、超意訳しまくりの、超簡単な説明としてしまおうと思っています。

これを読んで、なぁ～んだ、こんなもんかと思って頂き、楽しいプログラミングが出来る事を祈っております。

んでは次回よりデザインパターンの紹介と、それに伴う実装についてのお話を記載していきます。

そして、オブジェクト指向について、むちゃくちゃ意訳した為、偉い人が見たら発狂するかもしれませんので、多少細かい事だけ書いておきます。

もともと、むかぁ～しむかしは、構造化プログラミングというのが流行っていました。
これは、ロジックを構造化して、抜き出して再利用しやすいものにしましょうよっていう書き方です。

ところがどっこい、ロジックに渡すべきデータの内容が日増しに肥大し、データの管理が出来なくなってきた為、次は処理に使用するデータとロジックをまとめたモジュールというものに目がつけられました。

これで安心かと思いきや、モジュールに格納されるデータについての賞味期限が何時切れるのかがわからないという事態が発生するようになりました。

ってことで仕方がないので、今度はデータとロジックをまとめて賞味期限が何時切れるのかを明確にしたオブジェクト指向というのが出てきました。

これがオブジェクト指向です・・・・駄目だorz
これ偉い人が読んだら絶対発狂する(´ρ`)

私に小難しい説明は無理そうなんで、なんかわかる人がその辺まとめてくれてるから、そういう偉い人向けのはそっちに任せる。

ついでにMVVMはソフトウェアアーキテクチャパターンとなり、デザインパターンとは似て非なるものである。

この辺についても暇を見てつらつら書き綴っていきます。