- ベストアンサー
オブジェクト指向のインターフェースについて質問です
素朴な疑問かもしれませんが、真剣に根本的な疑問です よろしくお願いします 複数人でなく、一人でプログラムを作るときには インターフェースにはどんな使い方がありますか? 多人数でプログラムを作る場合にはクラスを作る人たちへの どんなクラスを作って欲しいかの設計メモ代わりになったり 必要なメソッドの作り漏れ防止の意味で使われると聞きました。 しかし、一人でプログラムを作る場合には わざわざインターフェースを作ってからそれを実装するのは どのような意味があるのでしょうか?
- みんなの回答 (6)
- 専門家の回答
質問者が選んだベストアンサー
明けましておめでとうございます。 >一人でプログラムを作る場合には 他の方も仰っていますが、オブジェクト指向は分析や設計で使うものです。 オブジェクト指向を使って分析や設計を行うなら、インターフェースも使われることがあります。 例えばJohnの親がPersonで、PersonとBirdがISpeakを実装する、といった感じです。 抽象クラスは主に概念上の親子関係を示し、インターフェースは主に機能上の共通性を示します。 こういった、抽象的な関係性の中でクラスやインターフェースは定義されているのであって、実装上の理由から定義されるわけではないですよ。 個人でも、きっちり設計したなら、インターフェースを使う機会も多いはずです。 それがオブジェクト指向ということであって、ただ動けばいいとか、便利とか、そういうものではないです。
その他の回答 (5)
- 中村 拓男(@tknakamuri)
- ベストアンサー率35% (674/1896)
インターフェースの利用法は大きく2種類あります。 (1) 共通のインターフェースを定義する。 オブジェクト指向で設計を行うとき、複数のクラスでグループを 作り、共通のメソッドを定義してクラスを実装するということを よくやります、これはとてもよく行う基本的な設計作業です。 この共通メソッドの定義は ■ インターフェース ■ 抽象クラス のどちらでも行うことができます。 インターフェースは全く実装を持たない抽象クラスと言えます。 既定の実装は不要ならインターフェースで定義したほうが若干楽です。 共通のインターフェースだけを利用して処理を行うコード部分は オブジェクトをインターフェースや抽象クラスとしてアクセスするように書くと クラスのグループに新しいメンバ(クラス)が加わっても、コードの書き換えが ほとんど発生しません。 (2) オブジェクトに多面性をもたせる。 ひとつのオブジェクトが2つのグループに属し、使う場面によって異なる顔を 持つことがあります。 例えば「部長」オブジェクトは「従業員」としてのメソッドと 「管理者」としてのメソッドを持つとしましょう。 部長を「従業員」として処理するコードと、「管理者」として 処理するコードの両方に渡したい場合、部長はある時は 「従業員」に見え、ある時は「管理者」に見えることが必要ですが、 「従業員」や「管理者」を抽象クラスを使って 定義することはできません(子に継承できる親クラスはひとつ)。 この場合はインターフェースで「従業員」や「管理者」を定義して 多重継承します。するといつでも「従業員」や「管理者」に キャストできるようになります。
お礼
なんとなく理解できました 実装上でもそのようなメリットもあるのですね しかし、この理由でも実装上のメリットだけでなく設計上のメリットも 含まれてるようにも感じますし、インターフェースは 設計的に大きな意味があるのかと感じました 勉強になりました ありがとうございました
- shiren2
- ベストアンサー率47% (139/295)
ANo.4の補足です。 >実装上の理由から定義されるわけではない この表現は分かりにくかったかもしれません。 実装段階の都合で使われるわけではない、と読み替えてください。 辞書的な意味での実装ではなく、段階としての実装段階のことです。
- Interest
- ベストアンサー率31% (207/659)
インタフェースと実装を分離しておくと、実装側が変わってもそのクラスを利用する側からみたら同じように見えるので、利用する側のクラスを変更しなくて済むというメリットがあります。 例として、プリンタを制御するクラスを作る事を考えてみましょう。インタフェースとしてプリンタクラスを用意しておき、実装はインクジェットプリンタクラスとレーザープリンタクラスで作り分けるようにすれば、プリンタクラスを利用する側は実装がどうなっているかは知らなくても、とにかくインタフェースさえ知っていればプリンタを使えるわけです。品質特性で言えば、インタフェースと実装を分けることにより、拡張性や移植性が高まるわけです。 他人の手に渡ることのないプログラムや使い捨てられるプログラムであれば、このような品質要求はおそらくないと思いますので、インタフェースと実装を分離するメリットはそれほどないかもしれません。 「そんなのオブジェクト指向の基本じゃないか!」と言われるとそのとおりで、じゃあインタフェース(interface)と抽象クラス(abstract)の違いって何、というのが次に湧いてくる疑問じゃないかと思います。
お礼
ありがとうございます これらの理由だと自分ひとりでやる場合には あまり問題がないのではと思いましたが、 多人数でやる場合にはこれらのメリットも生かされそうですね
- LancerVII
- ベストアンサー率51% (1060/2054)
こんにちは。 個人的には間違い防止でインターフェースを作るという考えはありません。 会社内でのプロジェクトでもうちの職場はそういった概念がありませんでした。 DAOの例では間違えの予防というよりはデータベースが変わった時に実際のDAOを変更しても再利用が簡単ということです。 現在のバージョンならGenericsが使えて、基本的にキャストミス等はおきづらくなりましたし、JavaDocをみつに作るようにして対応しています。
お礼
追回答ありがとうございます 再利用性についても勉強してみて たしかにそういうのがあるかもしれないと思いました ありがとうございました
- LancerVII
- ベストアンサー率51% (1060/2054)
こんにちは。 一人で作るとか複数人で作るとかではなく、単純にそういうクラス設計にしたい時にインターフェースを使います。 例えばDAOクラスにインターフェースを用意しておけば必ずもらいたいデータはそのクラスになります。 するとDAOクラスを呼び出しているクラスの変更がいらなかったり。 なんていうか言葉で表すのは難しいのですが、システム内の設計で必要になったら使う感じです。
補足
ありがとうございます すみません、例をあげて詳しく書けばよかったかもしれませんでした 説明不足でした たとえばそのDAOクラスのメソッドを呼び出すとき、 インターフェースを用意しておけば「必ず」目的の型になりますが 「必ず」というのは「間違った渡し方や使い方をする可能性」が あるのを予防するためだと思ったのですが、どうでしょうか? 他人が作ったものだと何かを勘違いしたり、 クラスやメソッドの意図が読み取れなかったりして間違ったことを する可能性があると思うのですが、自分で設計して 自分で書いたものを間違って認識することもあるのでしょうか? 何かを間違ったとしても、大昔に作ったコードをもう一度 書き換えようとするときでも、そのようなときは「あれ?どうだったっけ?」 と思ってコードを読んだりコメントがあればそれを読むと思ったんです。 「必ず」が保証されるためにインターフェースを使うなら、 ここはミスをしないと思えばインターフェースは使う必要がないと いうことなのでしょうか? インターフェースがミス防止のためという認識自体違うのでしょうか?
お礼
実装のときの実用性で作られるわけではないというので なるほどと思いました ありがとうございました