getter, setterの必要性

Question

こんにちは
現在C#を勉強しているのですが、個人的にgetter, setterの必要性が無いように感じました
わざわざprivateなフィールドに外側からアクセスするためなら、getter,setterなど書かず、publicにしてしまえばいいのではないでしょうか。目的がわかりません。コードが長くなるだけではないのでしょうか。privateにする意味は外側から、アクセスされないためなのに結局アクセスする際の名前が変わっただけでアクセスできてしまう...これは意味がないんじゃ..とかんじました。

Accepted Answer

色々メリットがありますが、
メリットの１つとして.** 値の正当性チェックを入れることができる。**などがあります。
下記のサンプルは[こちら](https://msdn.microsoft.com/ja-jp/library/w86s7x04.aspx)から転載しています。

```C #
public class Date
{
    private int month = 7;  // Backing store

    public int Month
    {
        get
        {
            return month;
        }
        set
        {
            // 正当性チェック：1～12以外の値は代入しない。
            if ((value > 0) && (value < 13))
            {
                month = value;
            }
        }
    }
}
```

Answer

か、か、「考えなしに使えること自体ラピッド開発ツール(RAD)の重要な目的の１つだから」じゃないかな。
http://d.hatena.ne.jp/Kityo/20150625/1435181833

Answer

私がよく書くやり方ですが
```C#
public int Count {
    get;
    private set;
}
```
これだけでも十分メリットがあると思いますよ。

Answer

ちょっと調べ切れてないところがあるため、間違っているところがあるかも知れません。最初のオブジェクト指向であるSimulaについてはよくわからなかったので、割愛しています。なぜ、同じ事ができるpublicなフィールドなどと言う物があるのか？という疑問に対する読み物として読んでいただければと思います。なぜ、getterやsetterの方が良いのかは他の回答者さんの回答をお読みください。なお、この回答は**純粋オブジェクト指向原理主義者の偏見に満ちています**。

---

getterとsetterの代わりにフィールドをpublicにすればいいという考えは間違っています。そもそも、フィールドにpublicを設定できるという**言語仕様そのものが間違っています**。publicなフィールドがある言語は間違った実装をいつまでも採用している**欠陥言語**なのです。

この間違いはC++に由来します。C++はCの仕様をそのまま拡張してオブジェクト指向を実現しようとしました。正当なオブジェクト指向であるSmalltalkのようなクラスを実装することもできました。それを実現したのがObjective-Cですが、話がずれるのでそれはまた機会があれば話しましょう。では、C++の開発者はどうしたかというと**構造体を拡張してクラスを作る**というとんでもない手法を生み出しました。

Cの構造体は単純です。ただのデータの羅列でしかありません。そこに、メンバーとして関数を足せば、オブジェクト指向っぽい何かになることに気付きました。あとは、適当にコンストラクタとか継承とかアクセス権とか定義すれば、オブジェクト指向っぽくコーディングできるようになりました。しかし、所詮毛の生えた構造体です。メンバー変数もメンバー関数も区別することができません。なので、メンバー変数をpublicにできるのは当たり前のことでした。

C++のオブジェクト指向は成功を収めました。構造体を拡張するという発想は内部構造が単純になるため、実装も簡単でした。その流れはPythonでも採用されましたし、C++からオブジェクト指向を抜き出したJavaがその路線を踏襲することも自明のことでした。Javaはオブジェクト指向の代名詞になるぐらいに流行し、C++の間違った実装こそがオブジェクト指向だと人々は思うようになりました。

そして、C#です。C#の先祖であるObject Pascal(Delphi)もまさしくその路線でした。また、Javaへの対抗意識を燃やしていたC#がJavaと同じような構造にすることで、Java開発者を引き寄せようという戦略としても、それは当たり前のことでした。こうしてC#にも構造体を拡張したなんちゃってオブジェクト指向が実装されてしまいました。

C++ではフィールドではなくメンバー変数であり、クラスは構造体の一種であるため、publicであることは気にすることはありませんでした。黒魔術師であるC++erにとって構造体であることこそが真実であり、オブジェクト指向の機能はおまけにすぎなかったからです。この間違いにいち早く気付いたのはJavaの開発者でした。彼らはpublicなフィールドを使わずに、privateにしてgetterとsetterを実装することを推奨しました。彼らはフィールドという存在をひた隠しにするべく躍起になりましたが、自ら課した互換性という縛りのために、開発者に永遠にgetterとsetterを書き続けることを強いりました。

そんな中、ある発明がありました。まるでフィールドのようにアクセスできるメソッドにすれば違和感もなくなるということです。C#のプロパティはまさしくそれでした。あたかもフィールドのようにアクセスできるgetterとsetterを実装できました。その中身がメソッドなのかフィールドなのかは見えないようにしたのです。さらに、自動的にgetterとsetterが設定されるような構文も追加しました。JavaにはできなかったことをC#はやってのけたのです。

しかし、publicなフィールドは残されました。負の遺産は消えていなかったのです。しかし、安心してください。C#は常に進化しています。そのような負の遺産も、コード分析をすればそいつを使うのはいけないよってちゃんと指摘してくれるようになっているのです。
[CA1051: 参照できるインスタンス フィールドを宣言しないでください](https://msdn.microsoft.com/ja-jp/library/ms182141.aspx)
さすがC#です。C#さえ使っていればオブジェクト指向は完璧です。単純なgetterとsetterも簡単に実装できます。Cに毛が生えたC++や、なんちゃってオブジェクト指向のJavaとは違います。C#さえ使っていれば問題ありません。Visual StudioやMSDNが勧めてくれる推奨を疑うことはMicrosoftに対する反逆です。Windowsユーザである資格がありません。C#さえ使っていれば幸せになれるのです。

---

オブジェクト指向するなら、純粋オブジェクト指向であるRubyがお勧めって回答にしようとしたんだけど、C#を勧める回答になってしまった。どうしてこうなった？

Answer

C#でgetter/setterというのがあまりしっくりこないのですが。プロパティのことでしょうか。

私も基本はプロパティにしますが、内部実装的なところではpublicフィールドにすることもあります。

積極的に使う理由としては、デバッグのしやすさというのがありますね。get/setのところでデバッグ出力などをして実行状況をトレースしたり、ブレークポイントを置いてロジックを確認したりということができます。

Answer

プロパティのいいところは、インターフェースに抜き出せるところなんですよね。
以下はどちらもその応用です。
[http://qiita.com/yuba/items/baceffbdbcfdc03f7945](http://qiita.com/yuba/items/baceffbdbcfdc03f7945)
[http://qiita.com/yuba/items/dd0b4f43ae311683363e](http://qiita.com/yuba/items/dd0b4f43ae311683363e)

Answer

たとえば以下の例だと、Kingaku の setter に 0 が渡された場合、KingakuStr は "0" になります。
Kingaku の setter が一度も呼ばれない場合は、空文字 "" です。
```C#
private int _kingaku = 0;
private string _kingakuStr = "";

// 金額 (数値)
public string Kingaku {
    get {
        return this._kingaku;
    }
    set {
        this._kingaku = value;
        this._kingakuStr = value.ToString();
    }
}

// 金額 (文字列)
public string KingakuStr {
    get {
        return this._kingakuStr;
    }
}
```

他にも

「"1" をセットされても "01" をセットされても０埋めして "01" としてセットする」 とか、
「null の場合は "***" を返す」 とか、

プロパティ (getter/setter) にしておくと、こういうのを
呼出側のことは気にしないで
内部で勝手に書き換えられる点などが便利ですね。

一旦ただの public 変数で書いてしまうと、後から変更するのは大変ですし。
プロパティ (getter/setter) にしておけば如何様にもできます。

Answer

フィールドを private にして、単純な値の設定・取得のアクセサを public にするのがカプセル化だよ。
というのは違います。間違っています。

カプセル化という観点で見るならば、おっしゃる通りです。全然意味ないです。
オブジェクトが持つ実データを書き換えれて、実データを取得できるので、
フィールドを public にするのと違いはありません。

それ以外の観点から見た時、意味がないのか？というと、そこは人それぞれじゃないでしょうか。
僕は、set や get とタイプした時に、補完でズラっと出てきて欲しいので、
アクセサは用意しますね。

影響範囲を調査するときも、setterの呼び出し階層をたどれば、setしている場所が分かりますし。
ブレークポイントも貼れますし何かと便利ですよ。
publicフィールドにすると、set と get 両方が該当してしまい、目視による確認になりますので。

ただ、前述しましたがカプセル化という観点からだと無意味です。
そこは、そう理解したうえで書くべきだと思います。

ところで、C#にはアクセサメソッドって文化はあんまりなくないです？
プロパティとして書きますよね？

`public string foo { set; get; }` みたいな。

Answer

既に先人の方たちが多くの[議論](http://fukumori.org/oo/why_use_getters_and_setters_j.html)をしています。リンク先にまとめがのっていますので、どうぞ。

関連した質問