カプセル化
アクセス修飾子というものをつけると、クラス・メンバ変数・メソッドの公開範囲を設定することができるそうです。
public,private,protectedと、アクセス修飾子はあります。
中でも、メンバ変数にはprivateを設定し、クラスとメソッドにはpublicを設定する設計方針のことを「カプセル化」と言うそうです。
どんなメリットがあるのか？
メリット①「代入前処理」
例えば、メンバ変数で int score;と設定する。
この時、int scoreは0～100までの数値でなくてはならないものとします。
もし、メインメソッドから直接数値が代入されてしまうと、範囲外の数値がきても、そのまま処理されてしまう。
それを防ぎたいときに使うのがprivateというアクセス修飾子。
例えば、if(0 <= s && s <= 100)…のようなものをメソッドで設定しておいて、設計図のメソッド経由でscoreが入るようにしておけば、範囲外の数値が入るエラーを防げる、というわけです。
メリット②「プログラムの修正範囲が狭まる」
例えば、メンバ変数で private int socre;と設定しているとする。
そして、この変数scoreをengScoreに修正することになったとする。
もし、メインメソッドから直接数値が代入される設定になっているとすると、メインメソッドも書き換えないといけない。
しかし、メソッド経由で入るようにしておけば、engScoreと修正するのは設計図クラスだけで済む、というわけです。
コードで見ると分かりやすい
メリット①について
メインメソッド9行目にて、stu1.setScore(-50)と設定しています。
こうすることで、設計図の17行目に値が飛んで、数値範囲のチェックをしてくれます。で、範囲内ならscore=sとなり、int score=s=-50となります。
しかし、これは範囲外なので、elseの処理へ進み処理されます。
もし、メイン9行目のstu1.setScore(-50)がstu1.score=-50となっていて、設計図のprivate int score;がint score;になっていたら、直接代入されてしまうわけです（「村山さん：-50点」と出力される）。
なので、このアクセス修飾子でそれを防ぐというわけです。
メリット②について
private int score;のscoreをengScoreに修正することになったとする。
最初に貼ったソースコードの通りだとすると、設計図のscoreの部分をengScoreにするだけで完了で、メインメソッドを修正する必要はありません。
しかし、すぐ上に貼ったソースコードのように直接代入している場合、メインメソッドも書き換える必要がでてきます。
こうして、修正範囲を狭めることができるというわけです。