728x90

중첩 클래스에는 4가지가 있다. 정적 멤버 클래스, (비정적)멤버 클래스, 익명 클래스, 지역 클래스 이중 첫번째를 제외한 나머지는  inner 클래스 이다. 메서드 밖에서도 사용해야 하거나 메서드 안에 정의하기엔 너무 길다면 멤버 클래스로 만든다. 멤버 클래스의 인스턴스 각각이 바깥 인스턴스를 참조한다면 비정적으로, 그렇지 않으면 정적으로 만들자. 중첩 클래스가 한 메서드 안에서만 쓰이면서 그 인스턴스를 생성하는 지점이 단 한 곳이고 해당 타입으로 쓰기에 적합한 클래스나 인터페이스가 이미 있다면 익명 클래스로 만들고, 그렇지 않으면 지역 클래스로 만들자.

728x90
728x90

태그 달린 클래스로 열거 하기 보단  계층주고 클래스를 만들어 상속하여 처리하는 방법으로 사용해야 한다. 

기존 클래스가 태그 필드를 사용하고 있다면 계층구조로 리팩터링하는걸 고민하자

728x90
728x90

자바 8 이전에는 기존 구현체를 꺠뜨리지 않고는 인터페이스에 메서드를 추가할 방법이 없었다.  자바 8이후 부터 디폴트 메서드 가 제공되어 추가가 가능해졌다.

인터페이스를 설계할 때는 여전히 세심한 주의를 기울여야한다. 

인터페이스를 릴리스한 후라도 결함을 수정하는게 가능한 경우도 있겠지만, 절대 그 가능성에 기대서는 안된다.

728x90
728x90

일반적으로 다중 구현용 타입으로는 이터페이스가 가장 적합하다. 복잡한 인터페이스라면 구현하는 수고를 덜어주는 골격 구현을 함께 제공하는 방법을 꼭 고려해보자. 골격 구현은 '가능한 한' 인터페이스의 디폴트 메서드로 제공하여 그 인터페이스를 구현한 모든 곳에서 활용하도록 하는 것이 좋다. '가능한 한'이라고 한 이유는, 인터페이스에 걸려 있는 구현상의 제약때문에 골격 구현을 추상 클래스로 제공하는 경우가 더 흔하기 때문이다.

728x90
728x90

상속용 클래스를 설계하기란 결고 만만치 않다. 클래스 내부에서 스스로를 어떻게 사용하는지(자기사용 패턴) 모두 문서로 남겨야 하며, 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜야 한다. 그러지 않으면 그 내부 구현 방식을 믿고 활용하던 하위 클래스를 오동작하게 만들 수 있다. 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다. 그러니 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 나을 것이다. 상속을 금지 하려면 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다. 

728x90
728x90

상속은 강력하지만 캡슐화를 해친다는 문제가 있다. 상속은 상위 클래스와 하위 클래스가 순수한 is-a 관계일 때만 써야 한다. 

is-a 관계일 때도 안심할 수만은 없는게, 하위 클래스의 패키지가 상위 클래스와 다르고, 상위 클래스가 확장을 고려해 설계되지 않았다면 여전히 문제가 될 수 있다. 상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자. 특히 래퍼 클래스로 구현할 적당한 인터페이스가 있다면 더욱 그렇다. 래퍼클래스는 하위 클래스보다 견고하고 강력하다.

 

 

is-a관계 

A는 B다  OOP 의 상속개념

 

 

has-a 관계 

A는 B를 가진다.  A가 B를 가지고 있다. 

728x90

+ Recent posts