package

• 패키지 아래에 클래스 사용시 package 패키지이름; 패키지 이름을 적고 시작해야 한다.
• 사용 할 클래스가 같은 패키지 경로에 있다면 패키지 경로를 생략해도 된다.
• 다른 패키지의 클래스를 가져오기 위해서는 패키지 전체 경로를 포함하여 클래스를 적자.
• a.pack.Stock과 같이 다른 패키지의 클래스를 가져올 때 매번 연결점을 포함해 길게 적을 수 없으니 import를 활용하자.
• 특정 패키지의 모든 클래스를 포함하여 사용하고 싶다면 클래스 이름 대신 "*"을 사용하자.
• 클래스 이름이 중복 될 경우(2개 이상) import는 하나만 가능하다. 나머지는 쓸 때마다 전체 경로를 포함해야 한다.
• 패키지 이름은 모두 소문자로 사용한다.
• 패키지 이름의 앞 부분에는 일반적으로 회사의 도메인 이름을 거꾸로 사용한다. (com.company.myapp)

보통은 무언가를 임포트 하는 것은 IDE에서 자동으로 처리해주므로 직접 작성할 일은 드물다.

접근 제어자의 필요성

우리가 이때까지 사용했던 public과 같은 표현은 접근 제어자이다. public으로 선언된 무언가는 어떠한 위치에 있어도 접근이 가능해진다. 그렇기에 public은 남용해선 안된다. 적절한 제어장치가 걸린 프로그래밍이 좋은 프로그램인 것 처럼, 자유도를 후하게 부여하면 많은 문제가 일어날 수 있다.

주식계좌에 대한 클래스를 만든다고 가정해보자.

특정 주식을 구매하는 메서드 buyStock()이란 것으로 주식 하나를 구매한다고 가정할 때 가진 주식수에 해당하는 필드(멤버변수) stockCount = 10은 11로 바뀔 것이다.

이때 stockCount가 public이라면 다른 곳(다른 파일)에서 stockCount = 100000라는 코드로 강제 수정이 가능해진다. 이러한 가능성을 차단하기 위해 우리는 다른 접근 제어자를 사용해야 한다.

개발자의 관점에서 접근 제어자의 필요성

위의 ac는 간단한 입금,출금 클래스로 만들어진 인스턴스이다. 이 클래스를 설계한 개발자와 이 클래스를 활용하는 개발자로 나뉘어 존재할 때(협업관점) 만약 클래스를 활용하는 개발자의 관점에서 ac를 생성하고 메서드를 활용하려고 보니 사진처럼 기능들이 나타난다면, public하게 나타나는 기능들은 암묵적으로 자신이 사용해도 괜찮은 것이라 생각한다. 이에 대해 사용을 조심한다 하더라도 쓰지 못할 곳에서 쓸 수 있도록 열어두는 것은 활용하는 사람에게 혼란을 줄 수 있다.

그렇기에 만약 계좌잔고에 해당하는 balance필드를 public하게 풀어준다면, 이 클래스를 활용하는 협업 개발자들은 곤란함에 빠질 것이다. "활용하라고 풀어준 것인데 이것은 활용되면 안될 변수같은데?"와 같은 쓸데 없는 생각에 일의 능률을 저하시킬 것이다.

접근 제어자의 종류

• private : 모든 외부 호출을 막음.(내부 호출만 허용)
• default : 실제로 아무 것도 적지 않을 때 default가 적용된다. default는 같은 패키지 안에서의 호출을 허용한다.
• protected : 같은 패키지 안에서의 호출은 허용, 상속 관계시 허용
• public : 모든 외부 호출을 허용

이러한 종류의 접근 제어자를 활용하여 적절하게 통제를 가해야 한다.

필드,메서드 레벨

4종류의 접근 제어자를 모두 사용 가능하다.

클래스 레벨

public과 default만 사용 가능하다. public의 경우 파일명과 클래스명은 같아야 한다.

캡슐화

접근 제어자를 잘 활용해서 적절한 통제 규칙을 만드는 것을 캡슐화 라고 한다. 감출 것은 감추고 오픈할 것은 오픈하도록 설계하는 것이다.

보통 데이터(멤버변수)는 숨겨야 한다. 필요성에서 언급했던 계좌잔고 변수를 오픈해서는 무서운 일이 발생할 확률이 존재한다.

기능에 있어서는 숨길 것과 그렇지 않은 것이 존재한다.

다시 자동차의 비유로 들어온다.
1. 액셀 밟기 기능 (사용자가 사용할 기능 -> public)
2. 액셀에 압력이 들어왔을 때 엔진에 있는 기름을 활용하여 바퀴를 굴리는 기능 (내부로직 -> private)

1번은 오픈해야하며, 2번은 오픈할 필요가 없다.