본문 바로가기
프로그래밍 놀이터/디자인 패턴, 리펙토링

[Effective Java] 클래스와 그 멤버의 접근성을 최소화하자.

by 돼지왕 왕돼지 2016. 10. 17.
반응형

 [Effective Java] 클래스와 그 멤버의 접근성을 최소화하자.


Access Control, access modifier, API, clone, collections.unmodifiablelist, decoupling, Effective JAVA, Elements, encapsulation, Final, information Hiding, override, package-private, parallel development, Private, private inner class, Protected, Public, public static final, Return, thread safe, [Effective Java] 클래스와 그 멤버의 접근성을 최소화하자., 가변, 가변 객체, 가변 필드, 개발, 결합도, 구성, 규칙, 내부 데이터, 다른 모듈, 맴버, 메소드, 멤버, 모듈, 배열, 배열 필드, 병행 개발, 보안 헛점, 복사본, 부담, 사용, 상세한 구현, 상호작용, 서브 클래스, 설계, 수정, 수정 불가, 숨기느냐, 스레드 안정성, 시스템, 시스템 개발, 영향, 위험 부담, 유연성, 유지보수, 인스턴스 필드, 인터페이스, 자동, 잘 설계, 재사용성, 접근 변경자, 접근 수준, 접근 제어, 접근 지시자, 접근 허용, 접근성, 정보 은닉, 제한, 참조, 최소화, 최적화, 캡슐화, 클래스, 테스트, 파악, 패키지 전용


-
잘 설계된 모듈과 그렇지 않은 것을 구분 짓는 가장 중요한 잣대는, 모듈 자신의 내부 데이터 및 그 외의 상세한 구현 부분을 다른 모듈로부터 어느 정도로 숨기느냐에 달려 있다.


-
모듈은 자신의 API 를 통해서만 다른 모듈과 상호작용한다.
정보 은닉(information hiding) 또는 캡슐화(encapsulation)이 그것이다.


-
정보 은닉은 시스템을 구성하는 모듈들 간의 결합도를 낮추어(decoupling) 모듈 별로 개발, 테스트, 최적화, 사용 및 수정이 가능하도록 한다.
또한 이렇게 하면 병행 개발 ( parallel development ) 를 할 수 있어 시스템 개발이 빨라진다.
모듈을 더 빨리 파악할 수 있고, 다른 모듈에 대한 영향을 주지 않고 수정도 가능하여 유지보수의 부담을 덜 수도 있다.
재사용성도 증가시키고, 큰 시스템 개발시의 위험 부담도 줄여준다.


-
접근 제어 ( Access Control ) 메커니즘
접근 변경자( access modifier ) private, protected, public 등을 제대로 지정하자.
각 클래스나 멤버의 접근 허용을 가능한 최소화 해야 한다.
최상위 클래스와 인터페이스의 경우는 패키지 전용(package-private)과 public 두 가지 접근 수준만 가능하다.
패키지 전용으로만 할 수 있다면 반드시 그렇게 해야 한다. 패키지 전용은 내부 구현에 더 큰 비중을 둘 수 있다.
만일 패키지 전용의 최상위 클래스나 인터페이스가 단 하나의 클래스에서만 사용된다면, 사용하는 클래스의 private inner class 로 만드는 것을 고려하자.


-
메소드의 접근 수준을 줄일 수 없도록 제한하는 규칙이 하나 있다.
서브 클래스의 메소드가 슈퍼 클래스의 것을 오버라이드 하는 경우 수퍼 클래스에서 지정한 접근 수준보다 더 낮은 것을 지정할 수 없다.


-
클래스에서 인터페이스를 구현할 경우, 클래스에서 구현한 인터페이스의 메소드는 반드시 public 으로 선언되어야 한다.
인터페이스의 모든 멤버들은 접근 지시자를 주지 않아도 자동적으로 public 이다.


-
인스턴스 필드는 절대로 public 으로 하지 말아야 한다.
인스턴스 필드가 final 이 아니거나 또는 가변 객체의 final 참조일 때 그 필드를 public 으로 지정하면 외부에서 이 필드의 값을 임의로 변경 가능하여 그 필드가 갖는 값을 제한 할 수 없게 된다.
public 가변 필드를 갖는 클래스는 스레드에서 안전성을 보장할 수 없다.
심지어 final 이면서 불변 객체를 참조하는 필드일지라도 public 으로 지정하면 그 필드를 뺴고 클래스 내부 데이터 구조를 변경할 때 유연성이 떨어진다.


-
요소가 하나라도 있는 배열은 항상 가변적이라는 것에 주의해야 한다.
클래스에서 public static final 배열 필드를 갖거나, 또는 그런 필드를 반환하는 접근자 메소드를 갖는 것은 잘못된 것이다.
이는 보안상의 허점이 될 수 있다.

Elements 내용의 변경은 허락한다는 가정 하에 Collections.unmodifiableList 를 통해 수정 불가능한 collection 을 return 하거나,
clone 을 통해 복사본을 return 하는 것이 좋다.



Summary


가능한 접근성을 줄여야 한다.
클래스를 설계할 때는 우선적으로 최소한의 public API 를 결정하고, 클래스나 인터페이스 및 멤버들이 불필요하게 API 의 한 부분이 되지 않도록 해야 한다.
상수로 정의하는 public static final 필드를 제외하고 public 클래스에서는 어떤 public 필드도 갖지 않아야 한다.
public static final 필드로 참조되는 객체는 반드시 불변 객체가 되도록 한다.





반응형

댓글