こんにちは、森川です。
先週の水曜から東京に来ていますが、風邪引いてで地獄です。

今日は「オブジェクト指向（ＯＯ オーオー）とはなんぞや？？（前編）」の続き。
前回はＯＯ（オーオー）とは、構造化プログラミングの延長上にある考え方ということ書いたと思う。

別の視点でＯＯについて考えてみたいと思う。

我々、プログラマー、システム屋として仕事をしている人達は、複数のプログラミング言語を扱う人が多いと思う。

例えば、ＷＥＢ系の仕事が多い人であれば、クライアントサイドで動くJavascriptとサーバーサイトで動くPHPなどなど。

でも、言語が変わったからと言って全くゼロから勉強しなおしってわけじゃないよね。
基本となるベースの考え方はどの言語もそのまま。
文法が若干違ったりするのでその部分を補いながら進めていく感じと思う。

だからシステム屋として、しっかりやっとかないといけないのは、プログラミングの基本となる、木で例えるならば幹の部分よね。

数多くあるプログラミング言語をすべて完璧に使いこなすなんて、実質は無理よ。
例えば、私自身もObjective CとかSwiftとかよー知らんし、全部なんかやろうなんて思ってない。

枝葉の部分まですべては無理。
だから幹の部分を太くしっかり育てたいという思いは、皆様も同じだと思う。

じゃー、ＯＯって木のどこに位置するかわかりますか？？
言わずとしれた木の幹の部分、枝葉ではないよ。

そう考えると、ＯＯの考え方は、JavaやC#のようなオブジェクト指向のプログラミング言語でしか使えないってわけではないんよね。
当然、文法的な制約があるので、言語によってはしばりが出てくる。

例えば、WEB系の言語はデータ型の定義がないものが多い。
だから考えなくても自然とポルモーフィズムになっちゃう。
VBAなんかはクラスは定義できるけど、継承なんかはできないよね。

では、具体的な例として、HTML，CSSについて考えてみたい。

例1
将来、変更したくない手を加えたくないうんざりするHTML、CSSとはどんなものでしょうか？？

私がうんざりするHTML

• 1. 意味がわからんdivやpがすげーいっぱいある。また、それらがネストしてる。
• 2. 必要かどうかわからんidやclassがたくさん割り振ってある。
• 3. いろんなファイルからCSSが適用されてて、もうわけわからん。

などなど

解説

HTMLとはこう書きましょうという記事ではないので、その辺はご了承を。
私が、触りたくないコードはやっぱりHTMLやCSSが複雑に絡み合ってわけわからんことなってるやつ。
将来の変更を考えるならばHTMLやCSSはなるべくシンプルにしたいのはみんな同じと思う。

今のご時世、疑似クラス、直下セレクタ、兄弟セレクタなどを使いまくれば、classとかid割り振らなくてもレイアウト作れちゃう。
実際、HTML5に移り始めた5-6年ぐらい前にそういうサイトが出てきて話題になったこともあったと思う。
確かにこういう作り方をすると、HTMLはシンプルになるって利点はあるよね。

でもね、その作り方じゃ今度は変更に弱くなるよね。

例えば、ページ更新が入って、隙間に一つdivをいれないといけなくなりました。直下セレクタがあると、この一つですべてがずれて狂ってくるよね。

逆にclassを割り振って、そのclassを使って操作するというのは、変更に強いよね。
場所とか関係から。

例えばこんな文書構造よくあると思う。手書きでごめん。

この複数あるsectionを操作する場合、classを割り振った方がよいのか？？それともnth-childのような疑似クラスがよいのか？？

sectionの並び順が変わることなんか普通に考えられるよ。
おそらくこの部分は、「変更が発生する」と考えるのが普通だと思う。
であれば、classを割り振った方がよいと思うよね。

じゃー、footerの部分は？？？？
おそらくほぼ変更はないだろうと考えるのであれば、classをなるだけ使わず、疑似、直下セレクタで攻めてもよいと思う。

上記に書いたような将来「変更する部分」と「変更しない部分」を切り分けるという考え方は、ＯＯでは至って普通の考え方。

ほら、Javaや#Cだけじゃない、HTML、CSSでもOOの考え方は役に立ってるよ。

例2

WordPressについて考えてみたい。
WEB制作においてWordPressのようなCMSははずせない。なぜか？？？
コンテンツの管理が非常に楽だからよね。
変更が発生する部分を管理画面から操作できるようにしておけば、ソースコードをいじらなくてもコンテンツを操作できるからとても楽ちん。

例えば、下記のようなギャラリーなどはどうでしょうか？？？

ここは間違いなく変更が入るよね。
だから、私であればカスタム投稿やカスタムタキソノミーを使いながら管理ページから追加削除できるように作る。
メニューやウィジェットだってそうよね。
変更がある可能性があるから管理ページ側で設定する。
でも変更する可能性が低いヘッダーやフッターは、わざわざそんなことしないheader.phpやfooter.phpに直接ハードコーディングするよね。

これもまさにOOの考え方よね。

ＯＯでは変更が入る部分は、テキストファイルやDBなどへ片っ端から追い出してハードコーディングしないように設計したりする。
例えば、設定関係の情報もそうだし、アラートで出力するようなメッセージなんかも変更が入る可能性があるから当然そうなる。
具体的なデータをがんがん外へ排出することによりプログラムがより抽象化されて変更に強く再利用性が高いシステムになっていくんよね。

これと一緒よね。変更が入る可能性があるパーツは、管理画面という外部へ追い出していくことにより、変更に強くなる。
だからサイト管理が楽になるんよね。

ほら、Javaや#Cだけじゃない、WordPressでもOOの考え方は役に立ってるよ。

ここで2つ例をあげたように、ＯＯの考え方はオブジェクト指向の言語だけなくいろんなところで使えるんよ。
つまり、ＯＯの考え方は、枝葉ではなくて幹にあたる部分であり、システム屋としてしっかり勉強しておきたい部分と思う。

逆に考えると、ＯＯについて理解を深めたいなら、JavaがC#がとか言ってちゃだめ。
言語が何かというのは関係なく目の前のコードに向き合うときは、ＯＯの思考回路で取り組み、この言語であればどのようにまとめていくのが最適かを考えていく。
そしてたくさんコードを読んで書いて悩む。
それの日々の積み重ねでだんだん理解が深まってくると思う。

次回以降は、OOを習得するためにやらなければいけないことについて書いていきたいと思う。

今日の独り言

帰広まで後2日、、、、しんどい、がんばろう。