俺による俺のためのオブジェクト指向講座。その１
せっかくの備忘録なので知識の整理を兼ねて自分のためのPerl講座を書いてみる。
いつか自分以外の人の役に立てればそれもまた嬉し。
オブジェクト指向
オブジェクト指向プログラミング（以下OOP）とは、「データ」（あるピクセルの色やファイルのサイズなどのあらゆる「属性」）と「手続き」（データを変化させる特定の処理手順）のひとまとまりを一つの「オブジェクト」（物体）と見なす設計技法のこと。
例えばペットボトルのお茶があったとして、
・容量 ・ラベルのデザイン ・容器の形 ・中身の色 ・中身の残量
などの「データ」と
・フタを開ける ・中身を出す ・中身を入れる
などの「手続き」が存在することは納得できるだろう。
このような「ひとつのモノ」に関する情報をひとまとめに記述したプログラムを作り、それを集めてひとつのアプリケーションを作り上げるのが「OOP」と呼ばれる技法。
用語
クラス
「このモノにはどんなデータと手続きが存在するか」を定義するもの。
言い換えれば「とあるモノの設計図」に相当する。
「ペットボトルのお茶というのはこういうモノなんだ」という説明のこと。
オブジェクト 又は インスタンス
クラスが実体化したもの。
「君の持ってるお茶」とか「机の上のお茶」などの個別の物体。
これらは「同じクラス」であっても「異なるインスタンス」である。
だって机上のお茶のフタを開けても君のが勝手に開くわけではないし。
そんなエスパーに私はなりた（ｒｙ
パッケージ
いわゆる「名前空間」。
アパートやらマンションの部屋番号のようなもの。
同じ部屋の中で「ポチ」って呼べば同じ犬が反応するが、お隣さんで「ポチ」と呼んでもウチのポチは反応しない。
プロパティ
それぞれのインスタンスが持つデータ。
各インスタンスが個別に保持している。
このお茶は200ml残ってるけどあっちのは100mlしかない、というようにデータの値はそれぞれ。
メソッド
「手続き」のこと。
インスタンスに対して実行するなにかしらの「操作」を表すことが多い。
「フタを開ける」「飲む」なんていう動作。
手続き型
ある意味OOPの対義語。
一連の処理の流れに沿って記述していくプログラミング技法。
最近は「やっちゃいけないもの」扱いされつつある。
理由は後述。
(`・ω・´)とりあえずこれくらいにしといてやるぜ！
なんでオブジェクト指向か
OOPの利点を裏返すと手続き型の弱点になる。
開発が大規模になるにつれて判明した手続き型の弱点といえば、
・分担しづらい
・使い回しがきかない
・修正しづらい
という辺りが主なところ。
手続き型で記述されたアプリケーションは、いわば編み物のようなもの。
ちょっと語弊があるけど、編み物は基本的に一人の編み手が最初から最後まで一連の流れをもって作り上げる。
「ここからここまでは私、ここからがあなた。じゃあ一緒に作業開始」とはいかない。
必ずどこかにかっこ悪い結び目ができてしまう。
しかも一度編み上げたものを別のものにするには完全にほどかないといけない。
大してOOPで記述されたアプリケーションは合体ロボ（これが言いたかった）。
1号機と2号機と3号機のジョイント部分の規格だけ決めておいて、あとはそれぞれが同時に作業を進めることができる。
さらに出来上がった各機を組み合わせる順番を変えて、ビームの撃てる空中向きの合体、ドリルを使う地上向きの合体、ミサイルを撃つ水中用の合体と、組み換えるだけでバリエーションを持たせることができる。
(ﾟ∀ﾟ)元ﾈﾀ分かる人は友達になろうぜ
利点はまだある。
他の機体とのジョイント部分さえ同じ規格で作れば、1号機だけを大幅パワーアップした新1号機にしたって合体に影響はない。
一部だけを作り直すことができるのも大きなメリット。
これが何の役に立つかというと
概念的な説明は上記の通り。
これが実務上どのように利点かというと。
アプリケーションを作り続けていると、「ほとんど同じだけど少し違う」ものを作らなくてはいけなくなることが意外と多い。
そんな時にどうするか。
(´・ω・)ｺﾋﾟﾍﾟって言った奴は後で職員室に来なさい
「少し違う」部分だけ新1号機にすればいい。
「同じ部分」と「違う部分」を予め分けて作っておけば、「違う部分」だけを作ればいいことになって作業量が減らせる。
しかも「同じ部分」は既に使って動作が保証されているんだから安心。
企業なら特にバグを出すわけにはいかないから、「工数」と「安全」が同時に得られる手段があるならそれを使いたくなるもの。
