アクセシビリティ
変数の前につけるやつ、ちゃんと考えてつけようね、みたいな話です。
変数の前につけるやつの話
//クラス
public class Piece
{
private int id; //これは派生先ではアクセスできない。外からもアクセスできない。
protected int life; //これは派生先でもアクセスできる。外からはアクセスできない。
public int message; //外からアクセスできる。もちろん派生先からもアクセスできる。
}
//派生クラス(継承する)
//Pawnクラスは、Pieceで定義された変数と関数をすべて引き継ぎます。
public class Pawn : Piece
{
}
派生先とかについては、抽象化のところを見てください。
継承を考えない場合は、privateにするべきか、publicにするべきかを考えましょう。
基本的には、変数はすべてprivateにするべきです。
なんでprivateにするの?
まず、「変数が外から操作できる」という状態が、設計的にどれくらいヤバいかをイメージしてみましょう。
まず、みんな、publicの変数を書き換えるのは良くないと思っているわけです。
変数がpublicということは、鍵をかけていない家みたいなものです。
田舎の家はだいたい鍵がかかっていませんが、まあそんなに盗難も起きませんよね。
これは良心とかではなく「べつに入る理由はない」「中に人がいたらどうしよう」「怪しい行動をしてつかまりたくない」みたいな感情が多いんじゃないかと思うのです。
ただ、何かを盗もうと思えば盗める状態ではありますよね。
だから必要に迫られたら、人間やっちまうんじゃないかと思うわけです。
プログラムの設計でも、同じようなことを考えます。
実装ができるのであれば、それが悪いことと知りつつもやってしまう事があります。
- 理由がなければ、クラスの変数にアクセスはしない
- しかし、必要があればクラスの変数を変更することはある
- 処理の流れの関係でクラスをいじらずに済むならとpublicの変数を直接書き換える…
といった感じです。
これを、コード上で「ブロック」するのが、privateにするということです。
publicにして書き換えられた変数は、コントロールできなくなる
だれでも好きなときに書き換えていいわけです。
だから、必ずそうなるという保証がありません。
よくやってまう変数としては、HPが当てはまるでしょうか。
復活処理を作りたいみたいな時。
HPを復活処理の前後で操作されると、HPがちょっと減った状態で復活するとか、ヘンなバグの原因になる可能性があります。
こういう時、だいたいは「復活中だったら処理をしない」とか、コントロールするためにif文を記述します。
これが、変数が外部から操作されていた場合、すべての変数操作をしている個所に判定式を書かねばならないです。
これは激しく面倒ですよね。
こういうことが起きないようにするために、メンバ関数を用意したりして、コントロールしやすいようにするのがお勧めされる書き方になります。
これはプロジェクトの中盤~後半で、じわじわときいてきます。
アクセサ、プロパティについて
後で詳しく書きます。
便利なので使っていきましょう。
public HitPoint { get; private set; }
みたいに記述するやつです。