제어자 : 클래스, 변수 또는 메서드의 선언부에 함께 사용되어 부가적인 의미를 부여
접근제어자 , 그 외..
static - 클래스의, 공통적인 -> 멤버변수, 메서드, 초기화 블럭
인스턴스 별수는 하나의 클래스로부터 생성되었더라고 각기 다른 값을 유지,
클래스변수(static멤버변수)는 인스턴스에 관계없이 같은 값을 갖음. 하나의 변수를 모든 인스턴스가 공유하기 때문
final - 마지막의, 변경될 수 없는 -> 클래스, 메서드, 멤버변수, 지역변수
변수에 사용되면 값을 변경할 수 없는 상수, 메서드에 사용되면 오버라이딩을 하 수 없게 됨,
클래스에 사용되면 자신을 확장하는 자손클래스를 정의하지 못함
abstract - 추상의, 미완성의 -> 클래스, 메서드
접근제어자 : 멤버 또는 클래스에 사용되어, 해당하는 멤버 또는 클래스를 외부에서 접근하지 못하도록 제한하는 역할을 한다.
접근제어자가 사용될 수 있는 곳 - 클래스, 멤버변수, 메서드, 생성자
private - 같은 클래스 내에서만 접근 가능
default - 같은 패키지 내에서만 접근 가능
protected - 같은 패키지 내에서, 다른 패키지의 자손클래스에서 접근 가능
public - 접근 가능
public > protected > default > private
접근 제어자를 이용한 캡슐화
get & set
멤버변수의 값을 읽는 메서드의 이름을 get멤버변수이름
멤버변수의 값을 변경하는 메서드의 이름을 set멤버변수이름
클래스 내에 SET, GET 메소드를 선언
SET 은 변수값을 할당하는 목적의 함수이기 때문에 인자를 받아야 하고
GET 은 변수값을 반환하는 목적이기 때문에 return 이 필요함
캡슐화의 목적은 다른 객체와 협력할 때 필요한 정보만 노출하는 것이라고 생각합니다.
그래서 개인적으로는 무분별한 getter / setter 를 지양하면 어떨까 싶어요.
getter/setter 가 캡슐화를 위해서 존재한다고는 하지만 캡슐화를 위의 목적대로 받아들인다면 getter/setter 가 캡슐화를 방해한다고 생각하기 떄문이에요. 어떠한 필드든 getter 와 setter 로 접근할 수 있기 때문에 이게 접근을 제어한게 맞나? 하는 생각도 들어요.