読者です 読者をやめる 読者になる 読者になる

ボクは昔、インターフェースを意識しなかった

いいこと書いてます。さすがOO厨。
オブジェクト指向のプログラムに込める「意図」 - 都元ダイスケ IT-PRESS


インターフェースがいまいち理解できないのには、コーディングする上で
一連の流れを一人の開発者が行う、ということも
挙げられるんじゃなかろうか。


それこそ、最近はDIがデファクトスタンダードなので
Modelの中で役割決めてレイヤー切って、インターフェース経由で呼び出して・・・というのが
あたりまえなんだけど。


一昔前なんて、まずはインスタンスをnewしてナンボみたいな感じだったから
何でわざわざインターフェースなんてまどろっこしいことやるんだろう?
って多くのC言語辺りから来た人は思ってたに違いない*1
だって、インターフェース経由だったとしても
・インターフェースを使用するクラス
・インターフェースの実装クラス
は一人の開発者がコーディングしてたでしょう?*2
「このメソッド呼び出したらどうなるかなんて、俺が作るんだもん、知ってるって」みたいな感じ。
インターフェース?newできないじゃん。使わねぇよ、みたいな(笑)


DIを使ってインターフェース経由で呼び出せば、インスタンスの生成やトランザクションとか
いろいろやってくれる恩恵が受けられる。
ただ、実感できる恩恵もないのにインターフェースを使う気にはならない。実装も手間がかかるし。
DIも使わない状況でインターフェースを意識できるのは、本当にオブジェクト指向を知っている人か
フレームワークを作る人くらいだったんじゃないかな?
多分、仕様書見てプログラミングする人の大部分は、言語がオブジェクト指向なものを使っているだけで
その実装は関数指向だったに違いない。だって、困らなかったんだもん*3


どこまでがそのメソッドの責務なのかを意識して記述できるから、テストもしやすくなるので
今はインターフェースを使うことに何にも疑問は抱かないんだけど。


それと、JavaDoc書こうってのは大賛成。
ただ、それだけじゃドキュメントとしては不足で、
メソッドで無く一連の処理の流れとして理解を手助けできるものも必要じゃないかなー、と思う今日この頃。

*1:含む自分

*2:画面側、ロジック側それぞれ開発チーム分けてやった案件は稀

*3:含む自分