オブジェクト指向プログラミング#
オブジェクト指向とオブジェクト指向プログラミング#
Object Oriented and Object Oriented Programing
最近はオブジェクト指向プログラミングと言うプログラミング設計が流行っています。以下OOP
OOとはモノを重視した考え方。
OOPとはそれをプログラミングに適用した設計です。
OO自体は多少の個人差はあっても覚えるのは難しくありません。
しかしOOPは洗練されたセンスも必要なので一朝一夕で習得出来ません。
オブジェクト指向は今や、プログラミング言語だけでなく、ソフトウェア開発の全てにおける総合技術となっています。
でもベテランしか扱えない、と言う訳でも無いのでちゃっちゃと覚えちゃいましょう。
よく、オブジェクト指向の説明の際に現実世界を全てオブジェクト指向で説明できる、という説明を見かけますが、これは全くの間違いなので注意しましょう。
wikiなので興味のある方はどんどん訂正・追加をしちゃってください。
今までのプログラミングと何が違うのか#
従来のCで見られるような非OOPでの主役は関数です。実装の最前線に立つのも関数でしたし、設計の最前線に立つのも関数でした。 何かしら作りたいと思い立ったとき、まず意識すべきなのはどういう機能を実装すべきかであり、プログラミングの実装力というのはその機能をいかにして関数のコードに落とし込むかということでした。
ところで、プログラミング言語の進歩というのは抽象化の進歩を大きく孕んでいます。
コンピューターが使われ始めた当時、Perl, PHP, Pythonなどのインタプリタ言語はもちろん、Cなどの言語もありませんでした。
プログラマーはコンピューターと機械語で、もっとも具体的な形で対話していたのです。
しかし、それではあんまりだということで、機械語命令にmov, jmpなどのアルファベットを割り当てたのがアセンブリ言語です。これが最初の抽象化とも言えましょう。0と1のもっとも具体的な世界から意味的に理解できるように抽象化された状態で対話するようになったのです。
もう一つの抽象化として、変数があります。これのおかげで、プログラマーはメモリに置かれたデータをより便利に、簡単に扱えるようになりました。「メモリのn番地におかれたデータ」をhogeとかfugaとかいう人間が理解しやすい名前で扱えるようになりましたね。
さらに時は進み、次に持ち込まれたのが関数というものです。
たとえば、今まで三角形の面積を求めるためには「入力された底辺、高さという二つのデータを掛け合わせ、2で割る」という手続きが必要でした。関数を使えば、これをtriangleとかいう名前の関数にして扱えます。
関数プログラミングの効能には処理を共通化でき、ソースコードの見通しがよくなるということもありますが、ソースコードを(変数のそれと同じように)より人間に理解しやすくできるということもありますね。
さて、長くなりましたが、オブジェクト指向プログラミングとはこの抽象化物語の続きにあるものです。
関数プログラミングでは設計の主役は関数でした。オブジェクト指向プログラミングでの主役は名前の通り、オブジェクトです。
関数が抽象化してきたものはtriangleだったら「『入力された底辺、高さという二つのデータを掛け合わせ、2で割る』という手続き」でしたが、オブジェクトが抽象化するものはアプリケーション上における役割です。
アプリケーションの例として２ちゃんねるのような掲示板を考えてみましょう。従来の関数プログラミングでは、スレッドを立てるor編集するor削除する関数、レスを書き込むor編集するor削除する関数、スレ一覧ページを表示する関数、1スレのページを表示する関数など、機能を中心に考えます(大事なのは、これも正しい方法であるということです)。
オブジェクト指向では、「アプリケーションにどういう役割をしてくれるオブジェクトがあればいいか」を考えます。
この場合ではスレッドを扱う役割のオブジェクトとレスを扱う役割のオブジェクトとページ表示の役割のオブジェクトがあればいいですね(実際にはもちろんもっとたくさんになるでしょう)。
人間の脳には限界があります。設計に登場してくるヤツらは「数が少なくて、しかも人間が理解しやすい形であること」を満たしていたほうがいいですね。それを実現する新しい手段がオブジェクト指向です。 オブジェクト指向で検索すると、抽象クラスを作って共通化！とかカプセル化で変数を触らせない！などの触れ込みがありますが、僕はオブジェクト指向が真価を発揮してくれるのは設計だと思います。抽象化とか、カプセル化というのはそれを助けるためのものに過ぎないのです。
より人間が楽をするための技術なので、肩の力を張らずに気楽に使っていきましょう。
原則･法則#
これを抜きにしてOOは語れません。
OOPの悪い設計はこれに反している
可能性が大なので知っておいた方が良いでしょう。
- 単一責任の原則
- 開放閉鎖原則
- リスコフの置換原則
- 依存関係逆転の原則
- インターフェイス分離の原則
- 再利用・リリース等価の原則
- 閉鎖性共通の原則
- 全再利用の原則
- 非循環依存関係の原則
- 安定依存の原則
- 安定度・抽象度等価の原則
- デメテルの法則
パターン#
デザインパターン#
GOF(Gang of Four)と言う偉い人達が纏めたOOPの良い設計です。
実装レベルに近いので覚え易いのですが、
その反面適切な使い方が分からず濫用してしまいがちなので注意しましょう。
詳しくはデザインパターンにて会いましょうノシ
参考リンク#
『アジャイルソフトウェア開発の奥義（ISBN-13: 978-4797323368）』の著者：Robert C. Martin氏による「Open closed principle」の和訳。OCP、LSP、DIPの各PDF Document.
技術講座、OO入門 、技術書籍紹介 、メーリングリスト、ほか オブジェクト指向に関するドキュメントなど。
オブジェクト指向を中心とする技術について実践、研究、発表するグループ
オブジェクト指向の“モヤッと”の正体を知りたくなったら
- オブジェクト指向プログラミング - 『Wiki っぽい場(あるいは 疑似脳内ネットワーク)』内コンテンツ
オブジェクト指向を勉強しようとして挫折した人向けの文書。C言語の基本を知っている人向け。
オブジェクト指向議論が目的ではなく、どの順番で説明すれば初心者に解りやすいだろうか、について書かれていることに注意。
このようなエラーが発生したら、上司に至急連絡を取り、障害を取り除かないといけません。
解説動画へのリンク
～ 「Lispは拡張可能な言語で，その内部でオブジェクト指向プログラミングが容易に行える」
と言う方が真実に近いだろう． ～CLOSは規格として定義済みなので，Lispがオブジェクト指向言語だと宣伝するのは嘘ではない．
しかしそれではLispを単なるオブジェクト指向言語だと見るという制限を設けてしまっている．
確かにLispはオブジェクト指向言語だが，それはオブジェクト指向モデルを採用しているからではない．
むしろLispの底を流れる抽象化技法の適用例にオブジェクト指向モデルが加わったに過ぎない ～初心者向け#
参考文献#
- アジャイルソフトウェア開発の奥義
ISBN-13:978-4797323368
- Code Complete 第2版 上、下
ISBN:4-89100-455-X,ISBN:4-89100-456-8
OOPの専門書、ではないし、これ一冊でOOPの学習が完結する訳ではありませんが、OOPに対して WHY? って思っている人なら読んでみるといいと思います。
（オヌヌメサイト でも紹介されていますが）@ITのBOOK Preview も読んでみて下さい。
参考リンク#
- Java＆オブジェクト指向参考書リスト（2007年版） - カレーなる辛口Javaな転職日記
- オブジェクト指向でなぜ作るのか を買ってみました - みねこあ - コメント欄も併せて
- 限りなき旅は続く - みねこあ - この本が正しく見える理由
- 憂鬱本を買ってみました - みねこあ
- 駄目なOO本の見分け方? - みねこあ
- 参考：[CLOS](http://sumim.no-ip.com:8080/wiki/607) - Wiki っぽい場(あるいは 疑似脳内ネットワーク) ↩