OOPのprivateとprotectedの使い分けについて質問です。ある書籍で「よほどの理由がない限りprotectedを基本とすべきだと個人的に思う」という趣旨のことが記載されておりました。

継承を想定する場合のみ

自分なら逆で、すべてのオブジェクトを継承されること前提に設計するな。

だから「基本は？」と聞かれると protected になる。

もちろん拡張性を考えた上でのメソッド切り分けになるけど。

あとは必要に応じて、継承が必要になればprotectedに変更

後で変更するのは（すべてではないけど）基本的に設計ミスだと思う。

ただ、この辺は個々の設計思想にもよるのでどっちかに決まってればいいんじゃないかと思う。

ただし、プロジェクトごとに明確にしておかないと後でややこしいけど。

＞あとは必要に応じて、継承が必要になればprotectedに変更すれば良いかと

＞考えております

１から作る場合はその方針でもOKですが、

１からつくったものを改造とか変更とかする場合に、

なぜ継承するかというと、基底クラス（オブジェクト）に変更を加えたくないからで

protectedに変更する時点で、継承する意味もあまり意味を成しません。

＞よほどの理由がない限りprotectedを基本とすべきだと個人的に思う

私もこれが妥当だと思います。privateで絶対に大丈夫な場合はprivateにする。

絶対に大丈夫でない場合は、protectedでしょうか。

「継承を想定する場合のみ」が、「よほどの理由」にあたります。理由があるので

protected以上の属性に・・。

javaを想定して回答します。

基本的にprotectedとし、明確な理由がある場合のみprivateとしています。

理由は↓。上の方々とほぼ同じです。

• 将来的に継承する可能性がある。
  • 継承させたくないものはfinal classと明示すべきで、どちらかわからないものは継承できる方向に倒した方が修正が少なくて済みます。
• テストが容易。
  • 「生成されたインスタンスに対して任意のタイミングでメソッドが呼ばれても正しい結果を返す」ように作る意識が働くので、クラス設計が綺麗になったりします。1つのクラスにprivateメソッドが乱立してフィールド更新のタイミングが読みにくい…とような設計を防げたり。

例えばPythonだと基本publicなわけで、「知っている人が使う/作る/保守する」「ソース・インスペクションを実施する」であれば、全部publicでもいーんじゃないかとも思っています。

基本的にはprivateを利用するようにしています。

tomoyuki28jpさんと同意見です。

参考：

http://d.hatena.ne.jp/bleis-tift/20070623

「さて、この後の「1.3.1 好ましい制限」でも、素晴らしい暴論を吐いてくれる。」辺りから参照

将来の*するかどうかも分からない拡張*のために現在のコードを汚すことはしてはいけないと思っております。また、修正する際に、「親クラスを変更しなくてよい」という考え方も可能ですが、逆に、「サブクラスから自由に利用してよい」という保障もありません。

それならば、基本privateにしておいて、どうしてもprotectedにする必要があるのであれば、しても構わないかという検証をへて、protectedに変更して利用すべきだと思います。

また、適当な依存関係のメトリクスなんかで評価すると、privateの方が結合度は小さくなるはずです。こんなもの計算したところで何にもならないですが。

ただ、このあたりはb-windさんがおっしゃるように設計思想というか文化みたいなものです。

どちらがよいかなんてことは明確にはないと思います。

かなり極端ですが、語弊を恐れず言えば、

何でも簡単に手軽にしたいというJava屋さんにしてみれば、protected支持だと思います。

しっかりきっちりやりたいというC++屋さんにしてみれば、private支持だと思います。

直接関係ないですが、デフォルトのアクセス制限が、C++ではprivateであるのに対し、Javaではpackage privateになっていることからも言語的にも設計思想があると思います。

個人的な意見ですが、何かの参考になれば。