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

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

新規登録して質問してみよう
ただいま回答率
85.50%
Java

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

オブジェクト指向

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

継承

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

Q&A

解決済

12回答

4875閲覧

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

退会済みユーザー

退会済みユーザー

総合スコア0

Java

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

オブジェクト指向

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

継承

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

2グッド

2クリップ

投稿2016/07/13 07:50

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

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

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

java

1public class Main { 2 public static void main(String[] args) { 3 Man man = new Man("hoge"); 4 man.Answer(); 5 } 6} 7 8abstract class Person { 9 private String name; //Personは誰しもnameを持つ 10 public Person(String name){ 11 this.name = name; 12 } 13 14 abstract String Answer(); //答え方は人それぞれ 15 16} 17 18class Woman extends Person { 19 Woman(String name){ 20 super(name); 21 } 22 public String Answer(){ 23 return name + "と呼んでちょうだい" //エラー 24 } 25} 26 27class Man extends Person { 28 Man(String name){ 29 super(name); 30 } 31 public String Answer(){ 32 return name + "と呼んでくれ" //エラー 33 } 34}

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


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

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

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

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


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

stereo_code, TetsuyaZama👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答12

0

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

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

投稿2016/07/13 08:02

masaya_ohashi

総合スコア9206

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 13:39

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

0

ベストアンサー

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

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

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

投稿2016/07/13 08:02

maisumakun

総合スコア145121

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 13:44

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

0

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

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

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

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

投稿2016/07/13 11:32

yohhoy

総合スコア6189

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 14:07

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

2016/07/21 01:57

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

0

こんにちは。

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

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

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

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

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

投稿2016/07/13 15:14

編集2016/07/13 15:15
Chironian

総合スコア23272

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 15:40

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

0

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

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

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

投稿2016/07/13 08:25

Zuishin

総合スコア28656

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 13:51

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

0

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

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

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

投稿2016/07/13 08:17

ozwk

総合スコア13512

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 13:49

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

2016/07/20 00:20

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

退会済みユーザー

2016/07/20 13:01

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

2016/07/20 14:05

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

0

こんにちは

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

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

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

です。どういうことかというと、たとえば、動く点のクラスがあったとして、それを動かす方法には、

  1. 座標のsetter/getterを提供して、動かすときには、それをアップデートするようなやりかた
  2. 座標は隠蔽して、moveメソッドでその点を動かすやりかた

がありますが、 2を採れと言っています。
1の方式は、そのクラスの振舞いをそのクラスの外から操作していることになってしまい、オブジェクト指向から外れるからということです。

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

投稿2016/07/15 04:29

TakaiY

総合スコア12666

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/15 15:31

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

0

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

投稿2016/07/13 14:22

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

0

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

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

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

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

投稿2016/07/13 14:06

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 14:19

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

0

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

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

投稿2016/07/13 12:30

A-pZ

総合スコア12011

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 14:14

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

0

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

投稿2016/07/13 09:02

aetos

総合スコア42

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 14:00

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

0

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

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

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

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

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

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

投稿2016/07/13 09:01

MasafumiOkamoto

総合スコア254

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2016/07/13 13:58

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

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問