質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.91%

サブクラスにおいてpublicメソッドを定義することについて

解決済

回答 4

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 652

TsuyoshiIwanaga

score 143

同僚と議論していたのですが、有識者の方にもご意見を伺いたく質問させていただきました。

個人的には「サブクラスにpublicメソッドを定義すること」はNGと考えています。
理由はポリモーフィズムが破壊される(?)からです。

ただし、スーパークラスのpublicメソッドをオーバーライドするためにサブクラスで同名のpublicメソッドを定義するのは問題ないと思いますので、正しくは「サブクラスにてスーパークラスには存在しないpublicメソッドを定義すること」がNGになります。

私自身オブジェクト志向をしっかりと理解している自信はないので、認識の間違いや他にも「こういう時はサブクラスにpublicメソッドを定義したほうがよい」といったケースがございましたらご教授いただけると嬉しいです。

どうぞよろしくお願いします。

追記

みなさまご回答ありがとうございました。
色々なご意見をいただき自信のプログラムの書き方を見直すきっかけにもなりました。

「トンカチをもつとなんでもクギに見える」とはまさにこのことですね。。

ベストアンサー悩ましかったのですが、maisumakunさんにさせていただきました。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • swordone

    2020/07/10 11:54

    「ポリモーフィズムが破壊される」の根拠をお願いします。

    キャンセル

  • TsuyoshiIwanaga

    2020/07/10 12:18

    サブクラスを他のサブクラスと入れ替えて使う想定のコードがあるが、
    あるサブクラスではそれが上手くいく一方で他のサブクラスに差し替えると動作しないような状況を想定していました。

    サブクラスAにしかないhogeメソッドを定義し、それと代替する想定のサブクラスBにhogeメソッドがない(かつスーパークラスにもない)場合にサブクラスAのインスタンスでしか動作しなくなってしまうため「ポリモーフィズムが破壊される」のかなと考えていました

    キャンセル

  • shiracamus

    2020/07/10 13:46

    質問から外れますが、サブクラス以外に interface や メソッドオーバーロード でも ポリモーフィズム を実現できますよ。
    https://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%95%E3%82%A3%E3%82%BA%E3%83%A0

    キャンセル

  • TsuyoshiIwanaga

    2020/07/10 14:22

    shiracamusさん、ありがとうございます
    ポリモーフィズムひとつとってもそれにまつわる色々な機能や実装方法があるのですね。
    勉強しなくては...

    キャンセル

回答 4

checkベストアンサー

+6

理由はポリモーフィズムが破壊される(?)からです。

されません。親クラスやインターフェースで参照する場合、サブクラス独自に作成したメソッドは見えませんので、ポリモーフィズムに何ら影響しません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/10 12:35

    maisumakunさん Zuishinさん
    ありがとうございます。そもそもの私の「ポリモーフィズム」に対する理解が間違っているようですね。
    Zuishinさんにいただいたご説明とコード例を読み返しつつもう一回勉強しなおしてみます。

    hogeメソッドを定義したインターフェースを用意すれば、サブクラスすべてにhogeメソッドが存在することが保証されるのでサブクラスを入れ替えても動作する = ポリモーフィズムと考えていたのですが、その理解が間違っていたのかなと思います(インターフェースを定義してサブクラスにメソッドの存在が保証されることと、ポリモーフィズムは別の概念)

    オブジェクト志向って難しいですね...

    キャンセル

  • 2020/07/10 12:37

    > hogeメソッドを定義したインターフェースを用意すれば、サブクラスすべてにhogeメソッドが存在することが保証されるのでサブクラスを入れ替えても動作する = ポリモーフィズムと考えていたのですが、その理解が間違っていたのかなと思います

    いえ、それは正しいです。そのようなインターフェースを「使っていない」から、メソッドがない事態に陥ったのではないのですか?

    キャンセル

  • 2020/07/10 13:57

    maisumakunさん、ありがとうございます。

    インターフェースを使うことでサブクラスが特定のメソッドを持っていない事態は避けることができると認識しています。

    皆さんの回答などをふまえて考え直すと、「親クラスにないpublicメソッドをサブクラスに定義すること」がポリモーフィズムを破壊してしまうのではなく「ポリモーフィズムで代替を想定したサブクラスのメソッドがサブクラスによって実装されていたりされていなかったりすること」になるのかなと思いました。

    そしてその状況を避けるための仕組みとして親クラスにインターフェースを実装してサブクラスすべてに必要なメソッドの実装を保証するということですかね?

    キャンセル

+5

単純に考えて、ポリモーフィズムが必要ないような振る舞いはサブクラスのメソッドとして定義するかと思いますが、いかがでしょう。

理由はポリモーフィズムが破壊される(?)から

「ポリモーフィズムを使う」という手段自体が目的と化していると感じました。

何を目的にポリモーフィズムを使うのかを洗い出して、それに準ずるものはスーパークラスからオーバーライドするなりインターフェースから実装するなりすると良いと思います。

ポリモーフィズムを使う目的(とメリット)がなければ、「サブクラスにpublicメソッドを定義することはNG」ではありません。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/10 14:02

    ありがとうございます。

    >ポリモーフィズムを乱用しているから親クラスがでかくなっている訳ではないと思います。ここは単純にクラス設計の話と思います。
    親クラスに複数の責任をもたせてしまうことが原因というのはもちろん大きいと思っています。

    一方で、本来サブクラスにPublicメソッドとして定義するだけにしておけば単純になるところを、過剰に親クラスにも同名のメソッドをつくったりすることが心当たりがありまして、それが親クラスの肥大化にもつながっているのかなと感じました。

    キャンセル

  • 2020/07/10 14:35 編集

    > サブクラスにPublicメソッドとして定義するだけにしておけば単純になるところ
    恐らくそれはスーパークラスに対して振る舞いを持たせるのではなく、インターフェースを通して振る舞いだけ持たせておくのが良いと思います。

    例えば、Takashi is Human, Masaru is Humanであり、Human can jump.だとします。

    ならば、
    ① TakashiとMasaruはHumanを継承し、HumanにはIJumpableを実装する
    ② Humanには実装を持たないためIJumpableが持つjumpメソッドを抽象メソッドとして定義する
    ③ TakashiとMasaruはjumpメソッドの実装を強制されるため、そこで振る舞いを定義する。
    といったノリです。

    こうするとHumanクラスは実装を持たないため、Humanクラス自体が肥大化することはありません。

    するとスーパークラスの具体的な実装が減っていくはずで、仮にそれが0となるようならHumanクラスが不要となります。つまり、Takashi can jump, Masaru can jumpとコードで表現するだけで良くなります。

    キャンセル

  • 2020/07/10 14:50

    インターフェースを用いてスーパークラスには振る舞いだけをもたせておくのがスマートですね。
    具体的なご説明でわかりやすかったです、ありがとうございます。

    キャンセル

+5

難しすぎたようなので、簡単に書き直します。

サブクラスをスーパークラスにキャストし、スーパークラスとして使うのがポリモーフィズムです。

サブクラスにあり、スーパークラスに無いメソッドは、ポリモーフィズムを使う以外の場所、つまりキャストしない場所で使います。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/10 12:49

    ありがとうございます!コード例までつけていただきわかりやすいです。

    ReadHelloWorldにてreader.ReadLine();としている箇所について
    readerに入っている中身がFileStreamのインスタンスであろうとNetworkStreamのインスタンスであろうとStreamから派生したクラスであればちゃんと"Hello World!"を取得してきてくれるということですよね(どうやって取得するかはそれぞれ異なるとしても)

    この状況がつまりはFileStreamとNetworkStreamを状況に応じて差し替えても動作する(どちらにもReadLineメソッドが実装されているから)という理解でした。

    キャンセル

  • 2020/07/10 14:08

    書き直しありがとうございます。

    >サブクラスにあり、スーパークラスに無いメソッドは、ポリモーフィズムを使う以外の場所、つまりキャストしない場所で使います。

    これをソースコード内に存在しないように無理な実装を普段やっていた気がします。。
    (デザインパターンでいうテンプレートメソッドのように大枠の処理の流れを親クラスで定義して、
    サブクラスでその中身を実装していく方法をよく使っています)

    キャンセル

+1

ポリモーフィズムを使いたいときに、サブクラスで拡張されたメソッドをつかわなきゃいけないのであれば、問題だろうと思います。(ポリモーフィズムが破壊されるの意味はこれであってますか?)

しかし、継承を使うのは何もポリモーフィズムのためだけではありません。もう一つ差分プログラミングという目的があります。

たとえば、

クラスAとクラスBとクラスCはそれぞれ、メソッドがコピペになっていたとします。
この場合、共通部分をクラスDにまとめ、クラスA〜CはクラスDの派生クラスとするとコードの重複を減らせます。

ところで、クラスA〜Cは全く違うコンテキストでつかわれるためクラスDにキャストされる必要はありません。

上記のような場合もあり、一概に継承を使うからポリモーフィズムがあるとは言えないこともあります。
(この場合、意味上でクラスDにまとめられるかとか、移譲でやったほうが良くないかなどの検討課題が個別に存在します、)

他にも、インスタンス化した直後は派生クラスで定義したメソッドは使うけど、実際の処理をするときにはポリモーフィズムを使って処理するなどのパターンがあります。

オブジェクト指向で可読性が高く書くことは重要ですが、どうすればよいかは常にコードを見ながら個別に判断したほうが良いと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/07/10 14:11

    ありがとうございます!
    よく考えるとおっしゃるように共通処理をまとめる目的で継承させますね。

    状況に応じて最適な実装を考えることが大事というのもすごく参考になりました。
    ありがとうございます。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.91%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る