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

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

ただいまの
回答率

90.51%

  • Java

    15781questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • オブジェクト指向

    325questions

    オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

  • 継承

    46questions

    継承(インヘリタンス)はオブジェクト指向プログラミングに存在するシステムです。継承はオブジェクトが各自定義する必要をなくし、継承元のオブジェクトで定義されている内容を引き継ぎます。

継承と隠ぺい(カプセル化)

解決済

回答 12

投稿

  • 評価
  • クリップ 2
  • VIEW 1,825

TakashiAihara

score 15

オブジェクト指向の能力強化を図るため、
ネットで調べた下記の原則にしたがって、クラスの設計を考えています。

・getter/setterは利用しない。
・フィールドは必ずprivateにする。

この時、継承を使った下記のようなコードについて考えてみました。
このサブクラスの中で、どうやってもnameに辿りつけません。

public class Main {
    public static void main(String[] args) {
        Man man = new Man("hoge");
        man.Answer();
    }
}

abstract class Person {
    private String name; //Personは誰しもnameを持つ
    public Person(String name){
        this.name = name;
    }

    abstract String Answer(); //答え方は人それぞれ

}

class Woman extends Person {
    Woman(String name){
        super(name);
    }
    public String Answer(){
        return name + "と呼んでちょうだい"   //エラー
    }
}

class Man extends Person {
    Man(String name){
        super(name);
    }
    public String Answer(){
        return name + "と呼んでくれ"    //エラー
    }
}


解決方法として、下記を考えましたが、どうしても納得のいくものが思い浮かびません。
何か良い方法は無いでしょうか。


1.Personにnameは持たせず、サブクラスで個別に持たせる。Answerメソッドはインターフェースに変更する。
⇒nameは誰しも持つという思想に反する。nameに関する処理、その他フィールドの追加等、一元管理ができなくなる。

2.getterを作る。
⇒原則に反する。

3.nameフィールドをprotectedにする。
⇒原則に反する。

4.そもそも、フィールドだけを保持させるPersonクラスが設計としておかしいので、処理させるメソッドを持たせて何とかする。
⇒結局getterになってしまいそうで、やり方がわからない。


継承を覚えたての初心者の質問で申し訳ありませんが、ご教示の程、よろしくお願いします。
※Newhalfクラスを持たせる未来が無ければ、Personが不要な気がしてきました。

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

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

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

    クリップを取り消します

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

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

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

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

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

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

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

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

    質問の評価を下げる

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

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

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

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

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

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

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

    詳細な説明はこちら

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

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

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

回答 12

+4

原則自体が無理があります。

すべてのフィールドをprivateにした上でgetterもsetterも無ければ親の持つ要素へアクセスする手段が存在しません。それはオブジェクト指向の「隠蔽」という要素は備えていますが、「継承」という要素をドブに捨てています。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 22:39

    ご回答ありがとうございます。
    そうだったのですね。継承について、誤解をしておりました。
    protectedにして、処理したいと思います。

    キャンセル

checkベストアンサー

+3

そもそも論ですが、その「原則」とやらが、ここでは本来適用すべきものでないように思います…というより、「getterを使わない」というのは乱暴すぎるように思えますので、できればURLを示してほしいものです。

Person.namePersonを継承するいずれもが使うものですから、privateではなくprotectedとするのが適当な場面です。

聞きかじったような一言半句を信じこんで無理を重ねるより、その言葉の「背景」を考えて適用すべきかそうでないかを判断しましょう。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 22:44

    ご回答ありがとうございます。
    オブジェクト指向についての理解を早く深めようとするあまり、迷走しておりました。
    getterについては、「経験を重ねるうちに、getterの必要がなくなっていく」というように書かれておりました。
    こちらで提示しても良いのかわかりませんが、slideshareで見たものです。
    http://www.slideshare.net/MoriharuOhzu/ss-14083300
    私が取り違えていると思います。叱咤激励を感謝します。

    キャンセル

+2

ネットで調べた下記の原則にしたがって、クラスの設計を考えています。
・getter/setterは利用しない。
・フィールドは必ずprivateにする。 

(他回答で既にさんざん言われていますが)上記のような"原則"は存在しないと思います。とはいえ、これらは一概に誤りということでもなく、あなたの解釈・理解が厳格すぎるとも言えます。

  • 前者「getter/setterは利用しない」は、絶対に利用するなという強い禁止事項ではなく、「何も考えず無条件にフィールドと1:1対応させたgetter/setterを作るな」程度のニュアンスと推測されます。
  • 後者「privateフィールドを使う」はカプセル化の観点から強く推奨されますが、例外として「継承先(子)クラスにだけ限定公開したければprotectedフィールドを使うこともある」となります。

本当にどうしてもあなたの言う"原則"に従う必要があるならば、Java言語では リフレクション(Reflection) という機能を使って実現することができます。ただし、ある種の裏ワザ的機能ですから、この機能を利用することは全くお勧めしません。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 23:07

    ご回答ありがとうございます。
    上記原則を適用することがオブジェクト指向に則ることだと決めてかかっていました。
    また、protectedが存在している意味も考えてませんでした。
    今後は柔軟な設計に取り組めるよう、精進します。
    また、リフレクションについては、上司から使うなと言われていたので、
    今回ご相談するに至ったわけですが、
    言われていなかったら、恐らくリフレクションに手を出していたのでしょうね・・・

    キャンセル

  • 2016/07/21 10:57

    リフレクションも候補には挙がっていたんですね。質問の状況ではリフレクションを使うべきでないので、上司の方のコメントは妥当だと思われます(よかったですね)。

    キャンセル

+1

ThoughtWorksアンソロジーのオブジェクト指向エクササイズの話でしたら
「フィールドはprivate」ルールは存在しないので
protectedにすればいいです。

それに加えてprivate縛りをしたいというなら
getterの代わりに、コールバックを引数に取るメソッドを作って、
メソッド内ではそのコールバックにnameを渡します。

そしてこれをgetterではないと言い張れば完成です。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 22:49

    ご回答ありがとうございます。
    申し訳ありません。
    「ボールを投げずにキャッチボールをしたい」と言っているようなものだと、
    後になって気付きました。
    また、コールバックについて調べてみました。
    このような方法があるのですね。勉強になりました。

    キャンセル

  • 2016/07/20 09:20

    今更なんですが、実装継承(javaでいうextends)はカプセル化を破っているのではという議論もあるぐらいなので、
    オブジェクト指向エクササイズみたいな極端な練習用ルールを適用するときは
    型継承か移譲を使ったほうが簡単です。

    キャンセル

  • 2016/07/20 22:01

    コメントありがとうございます。
    やっぱり、継承の利用は難しいのですね。
    フレームワークで定義されているクラスをみても、
    継承よりインターフェースが利用されていることがほとんどなので、
    恐らくそうなのでは・・・と思っていました。
    移譲はいわゆるコンポジションと捉えていますが、
    型継承とはどのようなものでしょうか。
    無知で申し訳ありません。

    キャンセル

  • 2016/07/20 23:05

    インターフェースの実装です。

    キャンセル

0

面白い原則をみつけたものですね。思わず笑ってしまいました。

すべて private にしたらたどり着けなくなった。
でしょうね。
そうでしょうとも。

一応その条件を満たしてプライベートフィールドにたどり着く方法がないわけではありません。
が、意味のないことです。
それはオブジェクト指向プログラミングではありません。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 22:51

    ご回答ありがとうございます。
    オブジェクト指向について誤解しておりました。
    何が出来て、何が出来ないのか。何のためにやっているのか、
    まだ分かっておりませんでした。

    キャンセル

0

なんでもそうだが、「ご利用は計画的に!」である。

class Personがabstractな時点で、それはクラスとして不完全であり、必ず継承して利用することが前提となる。
よって、フィールドやメソッドのスコープは継承先のサブクラスからどう見えて欲しいか、また、Personクラスとして見せた時にその多態性をどう見せるのかを考えるのが、クラス設計の大前提であり大原則である。

protectedというアクセス修飾子が何を実現するために存在するのか、考えるべきである。

getter/setterのあり方については、Qiitaのこの記事がさっくりとまとめてくれている。
この記事の中にも「オブジェクト指向では原則フィールドはprivateに保つべし。」とあるが、この記事の中では、継承関係にあるオブジェクトの話は出てこないので、別儀である。

こんな記事も見つけたが、結局は設計次第である。

もう一つ、乱暴な言い方をしてしまうと、「抽象クラスに引数付きのコンストラクタなど不要である(サブクラスからその値を参照できないのであれば)」である。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 22:58

    ご回答ありがとうございます。
    また、別記事まで提示をしていただき、ありがとうございます。
    「現実で見た時に、nameを必ず持つので、フィールドに定義する→原則をそのまま適用する」というものを設計だと思ってしまっていました。
    オブジェクト指向は(特に多態性は)相手から使いやすくするという考え方が前提であることを忘れていました。

    キャンセル

0

皆さんが回答してくださっているように name を protected にするのが妥当でしょう。
付け加えるとすれば、name が変更不可能であるなら final をつけるのがより望ましいと思います。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 23:00

    ご回答ありがとうございます。
    仰るとおり、nameをprotectedで設計し直そうと思います。
    また、nameも不変なので、finalも付け加えさせていただきます。
    ありがとうございます。

    キャンセル

0

アクセサ・ミューテータを使わずに、privateなフィールドに値をもたせようとする場合は、コンストラクタで初期値として与えるくらいしか残されていないでしょうね。

インスタンス化したときの値は不変なものとする場合にこのような制約をつける設計もありますが、その場合、継承しても親クラスのフィールドには一切アクセスできないので、意味のないものになるでしょう。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 23:14

    ご回答ありがとうございます。
    ミューテータという呼び方をすることを初めて知りました。勉強になります。
    デザインパターンを最近勉強し始めて、色々と混乱してしまってました。
    protectedにして、アクセス出来るようにしようと思います。

    キャンセル

0

話はそれますが、エクササイズ的には、出来る限りイミュータブル(変更出来ない)オブジェクトにするっていうのも、訊いたことがあります。コンストラクタまたは、コンストラクタから呼び出されたメソッド以外でインスタンス変数の変更を許可しないのです。(言語の仕様でなく変数のルールとしてです。)

コンストラクタ以外での変更が無いオブジェクトは、オブジェクトの内に外に状態についての考慮が必要ないすっきりとしたコードになるという考え方だったかと思います。

イミュータブルオブジェクトで検索するといくつか出てきますが、私が知っているのは増田亨さんが奨めていたことです。
http://codeiq.hatenablog.com/entry/2013/08/26/155959

ちょっと関係する話かと思いまして・・・

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/13 23:19

    ご回答ありがとうございます。
    なるほど、エクササイズについて読んだ(学んだ)ことが無いもので、勉強になります。
    また、興味深い記事をありがとうございます。
    イミュータブルについて心がけようと思います。
    フィールドについては出来るだけfinalで宣言出来る方が良さそうですね。

    キャンセル

0

今回、スーパークラスのフィールドをprotectedにして、見直そうと思います。
皆様、ご教示をいただきありがとうございました。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

0

こんにちは。

回答そのものは他の皆さんと大差ないので、すいません省略します。

maisumakunさんへのコメントにかかれていたオブジェクト指向できていますか?を見てみました。

単なるコーディング・ルールばかりで、オブジェクト指向の話が事実上含まれてないようです。
オブジェクト指向のポイントは、情報の隠蔽や多様性です。

しかも、インデントは1メソッド1レベルとか、細かくなりすぎるのでちょっと複雑なアルゴリズムを記述するとデバッグが悲惨なことになります。
この人が書いたプログラム、絶対デバッグしたくないですね。
昔、似たような考えで記述されたプログラムをデバッグしたことがあるのですよ。細かすぎるメソッドが異様にたくさんあるので思考がブチブチ千切れて、非常に苦労したことがあります。

ところで、本人が意図的に公開しているものにリンクを貼ることは何ら問題ないですよ。

投稿

編集

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/14 00:40

    ありがとうございます。
    社会的にも、非常に勉強になります。
    自分の中で正解を見つけようともがいて、このスライドに行き着いたので、
    今後の指標にしようとしてしまっておりました。
    進む方向性まで修正していただき、ありがとうございます。
    こちらでご相談をしてよかった。

    キャンセル

-1

こんにちは

もとになったスライドを見てみました。
僕としては言われているような悪い内容のものとは思えません。ちょっと極端かなとは思いますが。

焦点となっている、
・getter/setterは利用しない。
・フィールドは必ずprivateにする。 
ですが、これを実現するには、対応したスタイルが必要であるということです。

  • オブジェクトを操作するのではなくて、オブジェクトに指示するという考えかた。

です。どういうことかというと、たとえば、動く点のクラスがあったとして、それを動かす方法には、
1) 座標のsetter/getterを提供して、動かすときには、それをアップデートするようなやりかた
2) 座標は隠蔽して、moveメソッドでその点を動かすやりかた
がありますが、 2を採れと言っています。
1の方式は、そのクラスの振舞いをそのクラスの外から操作していることになってしまい、オブジェクト指向から外れるからということです。 

今回のnameについていえば、みなさんの指摘どおりprotectedにして、Answer メソッドで利用すればなにの問題もないはずですが、そもそもこのことを考えるのには向いていない題材だと思います。

投稿

  • 回答の評価を上げる

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

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

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

  • 回答の評価を下げる

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

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

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

  • 2016/07/16 00:31

    「オブジェクトに指示するという考えかた」ですね。心に留めておきます。
    ありがとうございます。
    「クラス設計は現実を反映する」ということについて、分かったような気がします。

    キャンセル

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

  • Java

    15781questions

    Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

  • オブジェクト指向

    325questions

    オブジェクト指向プログラミング(Object-oriented programming;OOP)は「オブジェクト」を使用するプログラミングの概念です。オブジェクト指向プログラムは、カプセル化(情報隠蔽)とポリモーフィズム(多態性)で構成されています。

  • 継承

    46questions

    継承(インヘリタンス)はオブジェクト指向プログラミングに存在するシステムです。継承はオブジェクトが各自定義する必要をなくし、継承元のオブジェクトで定義されている内容を引き継ぎます。