Whiteship's Note


[Expert One-on-One J2EE Design and Development] J2EE 프로젝트를 위한 설계 기술과 코딩 표준 1

Spring/J2EE D&D : 2009.09.18 11:37


참조: Expert One-on-One J2EE Design and Development 4장

좋은 코드란 무엇인가?

- 좋은 코드는 엄청난 변경이 필요없이도 확장이 용이하다.
- 좋은 코드는 읽기 쉽고 유지보수가 편하다.
- 좋은 코드는 문서화가 잘 되어있다.
- 좋은 코드는 나쁜 코드가 발생할 여지가 적다.
- 좋은 코드는 테스트하기 편하다.
- 좋은 코드는 디버깅하기 편하다.
- 좋은 코드는 중복 코드가 없다.
- 좋은 코드는 재사용된다.

J2EE 애플리케이션을 위한 객체지향 설계 권고사항

많은 개발자들이 J2EE API를 익히는데 시간을 많이 소비하지, 좋은 코딩 습관을 기르는데는 너무 시간을 투자하지 않는다. SUN의 J2EE 예제 애플리케이션만 봐도 그런 걸 알 수 있다.

저자(로드존슨)의 경험을 바탕으로 볼 때 좋은 객체지향 원칙을 따르느 것은 탁상공론에 그치는 것이 아니라 실용적인 가치를 전해준다.

객체지향 설계는 (J2EE나 심지어 자바 같은) 특정 구현 기술 보다도 더 중요하다. 좋은 프로그래밍 습관과 적절한 OO 설계는 좋은 J2EE 애플리케이션의 기반이다. 나쁜 자바 코드는 나쁜 J2EE 코드가 된다.

인터페이스를 통해 의존성 낮추기(Loose coupling)

"구현체가 아닌 인터페이스를 사용하여 프로그래밍하라."
Progeam to an interface, not an implementation.

인터페이스 기반 접근방법의 장점

- 호출하는 쪽 코드를 변경하지 않고도 구현 내용을 변경할 수 있다.
- 인터페이스 구현의 자유. 오직 하나의 클래스 상속에 모든 걸 맡길 필요는 없다.
- 간단하게 테스트 구현체와 스텁 구현체를 만들어 제공할 수 있다.

딱딱한 상속 보다는 객체 조합을 선호하라(Composition)

"클래스 상속보다 객체 컴포지션을 선호하라"
Favor object composition over class inheritance

C++과 달리 자바의 클래스 상속은 한개의 클래스만 상속할 수 있다. 클래스 계층 구조는 매우 엄격하다. 클래스의 구현체 일부만 바꾸는 것이 불가능하다.(상위 클래스를 바꾸면 나머지도 다 바뀐다는 뜻인듯.) 하지만, 인터페이스로 그 부분을 (Strategy 패턴과 위임을 사용하여)캡슐화하면 문제는 해결된다.

객체 컴포지션은 클래스 상속보다 훨씬 유연하다. 자바 인터페이스는 위임을 자연스럽게 만들어준다. 객체 컴포지션은 -호출하는 쪽에서 행위를 표현하고 있는 인터페이스의 구현체를 주입하여- 객체의 행위를 실행중(런타임)에 변경할 수 있게 해준다. Strategy와 State 패턴이 이런 접근방법을 사용한다.

클래스 상속이 잘못 사용되는 예

- 간단한 인터페이스 구현이 필요한 상황인데도, 사용자가 추상 또는 구체 클래스를 상속받아 쓰도록 강제한다.  이렇게 하면 사용자 코드가 자신만의 상속 구조를 만들 수 있는 권한을 빼앗는 것이다.

- 하위 클래스가 사용할 헬퍼 메서드들을 상위 클래스에 놓고 클래스 상속을 사용한다. 만약 그 클래스 계층구조 밖에서 헬퍼 메서드를 호출할 필요가 있다면 어떻게 되는가? 객체 컴포지션이 낫다.

- 인터페이스 대신 추상 클래스를 사용하는 경우. Template Method 패턴처럼 추상 클래스가 매우 유용할 떄도 있다. 하지만 추상 클래스는 인터페이스의 대체제가 아니다. 인터페이스를 구현하는 유용한 과정일 뿐이다. 타입을 정의하고자 추상 클래스를 쓰지는 말아라.  다중 상속이 막혀있는 자바에게는 문제가 될 수 있다.

인터페이스는 간단하게 유지할수록 그 가치가 극대화 된다. 인터페이스가 복잡해지면 많은 양의 코드 구현을 해야하기 때문에 추상 클래스 또는 구체 클래스 상속을 강요하게 될 것이다. 따라서 그 가치가 떨어진다. 인터페이스의 적덜한 세밀도가 중요한 경우이다.
 
인터페이스 상속(클래스로 부터 기능을 상속받는 것이 아니라 인터페이스를 구현하는 것)은 클래스 상속보다 훨씬 유연하다.

그럼 클래스 상속이 나쁘다는 걸까? 전혀 아니다. 클래스 상속은 객체 지향 언어에서 코드를 재사용하는 강력한 방법을 제공한다. 하지만 높은 수준의 설계 접근 방법 보다는 구현 방식으로 생각해야 한다. 애플리케이션의 전반적인 설계로 강요하기 보다는 그 사용 여부를 우리가 선택할 수 있어야한다.


top