とりあえずインターフェース入門/オブジェクト指向プログラミング心得 - とりあえず雑記帳(跡地)

まず初めに、僕が日頃から感じていることをツラツラと書いてみます…。
なお、あえて極論を並べているので、いろいろとツッコミどころはあると思いますが(汗

一つ、オブジェクト指向以前のプログラミング手法も重要だ

オブジェクト指向プログラミングのスタイルと、それ以前のプログラミングスタイルを別物と考えてしまう方も時々いますが、
クラス内部でのメソッド分割やメソッド内の処理記述については、構造化手法等で培われた知見を十分に生かす必要があります。
その上で、クラス間での責務の配分等について、オブジェクト指向独自のノウハウが追加される雰囲気です。

つまり、プログラミング自体の経験が浅い方は、先達の意見に耳を傾け、また過去のプログラミング言語の経験が豊富で、
これからオブジェクト指向言語を学ぼうとする方は、過去の経験は全然無駄にならないので自信をもってください。

一つ、オブジェクト指向「プログラミング」とオブジェクト指向「分析」は別物と考えておくほうが幸せ

確かにオブジェクト指向の大きな長所として、分析/設計/実装(プログラミング)の工程を通じて、「クラス」という概念を一貫して利用できる点があります。
かといって、分析フェーズは概念の分類が重要なので、クラス数やクラス階層が複雑になりがちです。それをそのまま実装フェーズでもクラスとして実装すると、
クラス数が爆発してしまいます。分析フェーズではクラスとして分類していた概念を、実装フェーズでは属性値で区別するケースも良くあります。
ということで、「分析は分析、実装は実装」と割り切ったほうが気楽です。

一番マズいのは「オブジェクト指向では、分析と実装がイコールになるべきだ」という、不毛な原理主義に陥ることです。

一つ、オブジェクト指向「プログラミング」のメリットを最大に生かすのは「フレームワーク構築」だ

オブジェクト指向「プログラミング」によって得られる最大の利益は、メイヤー先生がおっしゃる「Open-Closed Principle」に基づいた設計による、
「変更することなく機能を拡張できる」ことであり、それはまさに、変更不要な部分を「フレームワーク」として構築することに他ならないのです。

もちろん、クラス分割による判りやすさ等もありますが、それはオブジェクト指向以前から構造化プログラミング等で行われていたことを
クラスにも適用しているだけです。

なお、ここでいう「フレームワーク」とは、Strutsのような汎用的なものだけではなく、かなり目的を限定したフレームワーク(今回の「二項演算フレームワーク」とか)も含めます。
むしろ、アプリケーション毎に、特化したフレームワークが出来上がるのが通常のスタイルと考えてもイイです。

一つ、クラス継承(extends)はオブジェクト指向プログラミングの本質ではない

「オブジェクト指向プログラミング=クラス継承をカッコよく使う」というイメージは巷に溢れています。結果的にカッコよくなってしまうのイイのですが、
慣れないうちは、何だかクラス継承することを目的として、トンでもないクラス階層を作ってしまうこともあります(以前の自分)。

先に挙げた「Open-Closed Principle」を実現するのに必要な「多態性」ですが、これを実現するにはインターフェースがあればよく、クラス継承は「無くてもイイ」のです。
クラス継承は、インターフェースを実装(implements)するクラスは概ね似通ってくるので、それらを共通的な基底クラスとして束ねることで実装が楽になる、程度のものです。

本質はインターフェースによる多態性の実現であり、クラス継承はそれを実装する上での便利機能に過ぎません。
まずインターフェース→実装クラスが似てきた→似てる部分を基底クラス化→ようやくクラス継承実施、という順番に慣れましょう。

次→サンプル～二項演算