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


[봄싹] 스프링 레퍼런스 3.0 번역 시작



http://springsprout.org/wiki/464.do

3.0 레퍼런스 번역을 꾸준히 하겠습니다. 그동안 블로그에 조금씩 번역해서 올려두기도 했었는데 아무래도 레퍼런스 글은 블로그에서 찾아보는게 불편해서 봄싹 위키에 정리하기로 했습니다.

일단은 저 혼자 시작합니다. 하지만 봄싹 회원이라면 누구나 위키 페이지를 추가/수정/이동 시킬 수 있기 때문에 자유롭게 참여하실 수 있습니다.

정해진 틀도 없고 파트를 나누지도 않았지만, 봄싹 사이트도 처음에는 이런 방법으로 개발을 시작했습니다. 지금은 제법 틀도 갖춰져 있고, 특정 모듈 또는 기능 담당자(? 라기 보단 스스로 책임을 느끼시는 분들)도 있습니다. 수직 구조로 누가 누구에게 지시하거나 일을 나눠주지 않고 수평구조로 서로 토론하며 자신이 만들고 싶은 기능을 마음대로 구현해 넣고 있습니다. 레퍼런스도 이런 방법으로 번역을 완성할 겁니다.

기여(?).. 흠. 참여하고 싶으신 분들은 언제나 대환영입니다.

파이팅!

ps: 위키 수정/추가시 포인트를 계산해서 위키 기여도를 측정해야겠군요. 가장 많이 기여한 분에게 봄싹 티셔츠라도...

ps: 위키 미리 보기 화면과 실제 화면이 좀 다른데;; 아마도 조만간 소내기형이 수정해주지 않을까 싶네요... 형 수정해주세요.. ㅠ.ㅠ


top