set get のカプセル化のお話

Question

よくc++などで
下記のような作りがありますが、
カプセル化をするためにaをprivateにしているのに
Setaを作ってしまうと値の変更ができてしまいますが、
これは明示的にSetaを呼び出さないと変更できないので許されているのでしょうか？

class B
{
private:
float a;
public:
float Geta(){return a;}
void Seta(float x){ a = x;}

}

Comments

[dodox86]

[不適当な指摘なので削除]

Answer 1

許す許さないを決めるのは自分なので、納得すれば良いのでは無いでしょうか？納得できないなら駄目。

お書きのように、「要不要の検討を十分せずにセッター・ゲッターを定義する」のは、カプセル化を破壊する行為ではあります。

例えば、「成人かどうか？」を判断する際に、人オブジェクトからゲッターで年齢を取得して20と比較するのでなく、人クラスに定義された「（真偽値を返す）成人判断メソッド」を呼び出してメソッド内で判断してもらうのがカプセル化的はに正しいやり方です。

Answer 2

カプセル化をするためにaをprivateにしているのに

Setaを作ってしまうと値の変更ができてしまいますが、
これは明示的にSetaを呼び出さないと変更できないので許されているのでしょうか？

カプセル化を何だと思っての疑問なのかわかりませんが、カプセル化というのは「クラスの内部データ構造をクラス外部に対して隠蔽し、それを変更する操作のみを公開すること」です。

つまり「変更できる操作を公開する」事は定義上何の問題もありません。

これは「データ」と、setter/getterというそれを変更・取得するための操作、というインターフェイスを分離することで、インターフェイスに変更がない限り、クラス内部でどのような変更があろうと、そのクラスを利用する他の箇所への影響をない事を原理的に保障するためのものです。

Answer 3

aの実際の制御権はクラスが保持しているわけで、その意味でOKというところではないでしょうか。

例えば、実はaはMIN以上MAX以下に制限されなければいけない、何ていう事情があったときに、セッタ経由であればセッタにその範囲制限を組み込むことでクラスの責任範囲でそれを保証できるわけです。

aをpublicにしてしまったらそういうわけにはいかず、外部に値の制限をお願いすることになってしまい、仕様の依存関係がでてきてしまいます。
(今回は実際にはそういう制限は'たまたま'なかったわけですが)

もちろん、セッタゲッタがずらーっと並ぶとしたらそのクラスの設計ってどうなの? ということにはなりますね。

Answer 4

たとえば、自動車の運転で、スピートを上げ下げするのは、アクセルかブレーキであり
セットスピードじゃないです。

もちろん外部からスピードを勝手に変更されないようにprivateにしますが、
属性を外部からアクセスできないようにすること、それ自体はカプセル化ではないと考えます。
※もちろんカプセル化の一部であり、カプセル化を実現するための手法ではあります

カプセル化、セッター、ゲッターの意義を教えてください。

Answer 5

片端からアクセサを用意するのはカプセル化に逆行する懸念があります。
しかし何かと便利ですし、直接書き換えるよりは遥かにマシなので『とりあえず』用意されがちです。

Comments

[LouiS0616]

まあ利用者から見た『概念的な属性』と、実装者から見た『実装上の属性』が対応する場面ならばアクセサがあるのは自然です。

Answer 6

そういうもん、だとしか言いようがないです。
外部からaを変更するためには必ずSetaを経由しなければならない、ということですね