본문 바로가기

카테고리 없음

팀원에게 객제지향 개발을 유도하기 (3/3)

팀원에게 객제지향 개발을 유도하기 (1/3), 팀원에게 객제지향 개발을 유도하기 (2/3)에 이어서 포스팅 합니다.

+ 2008년 초 레거시 코드를 스프링 프레임워크 IoC로 이식하며

> 잠깐, 왜 인터페이스와 인터페이스를 상속하는 구현 클래스를 만드는 방식으로 프로그래밍 해야 하는 거죠?

팀원에게 객제지향 개발을 유도하기 (1/3)에 객체지향스럽게 짠다는 의미를 대상 요소를 잘 추상화 하여 추상화의 장점을 잘 살리는 것이라고 했습니다. 인터페이스와 인터페이스를 상속하는 구현 클래스를 만드는 것이야 말로 바로 객체지향 추상화의 기본이 되는 프로그래밍 방식입니다.

그리고 스프링의 IoC(Inversion Of Control)기능이 바로 인터페이스와 인터페이스를 상속하는
구현 클래스 방식의 객체지향 개발을 편하게 지원하기 위해서 만들어졌습니다.

만약 인터페이스와 인터페이스를 상속하는 구현 클래스 방식으로 프로그래밍을 하지 않는다면 객체지향 개발을 하는 의미도 없어지고, 스프링을 쓰는 의미자체도 거의 없어지게 됩니다.

인터페이스와 인터페이스를 상속하는 구현 클래스 방식으로 개발을 해야 객체지향의 추상화 이점을 최대한 살릴수 있고, 스프링 프레임워크를 잘 쓰고 있는 것이며, 디자인패턴과 리팩토링의 출발이자 핵심이라고 할 수 있습니다.


사용자 삽입 이미지
[전형적인 인터페이스와 인터페이스를 상속하는 구현 클래스 방식]



> 스프링 프레임워크에 실제로 레거시 코드(예전에 짠 소스)를 어떻게 이식했는가..

당시 우리 회사의 레거시 코드는 블랙잭, 햅틱, 아르고, 아이폰등의 공통으로 묶일 수 있는 객체들이 분리되어 있었고, 전화 걸기, 전화 받기, 통화, 부가 기능등이 별도의 유틸리티 기능처럼 분산되어 있었습니다.

일단 스프링의 IoC를 활용하기 위해서 인터페이스와 인터페이스를 상속하는 구현 클래스 방식으로 리팩토링하기로 하여 공통으로 묶일 수 있는 객체들을 하나의 객체 가족 그룹으로 묶었고, 분산된 유틸리티 기능들을 역시
하나의 객체 가족 그룹으로 묶었습니다.

그 다음 스프링 IoC 기능으로 빈설정을 하니 바로 이식이 되더군요. 레거시 코드를 스프링IoC로 이식하는데 하루정도 밖에 걸리지 않았습니다. 객체지향과 인터페이스 개념만 알면 이식하기 어렵지 않았습니다.

사용자 삽입 이미지
[절차지향같은 경우 하나의 가족으로 묶어서 추상화 할 수 있는 핸드폰 관련 요소들도 별도의 함수로 분리되어 있다.]
 
사용자 삽입 이미지
[위의 분산된 요소를 하나의 핸드폰 가족으로 묶어서 추상화 하고, 통화방법 및 무선인터넷 기능 같은 경우 Strategy Pattern으로 묶어서 다시 추상화 하여 골라 쓸 수 있다.]


> 스프링 IoC 설정의 사용 예

<bean id="핸드폰" class="블랙잭">
    <property name="통화방법" ref="통화방법"/>
    <property name="무선인터넷 ref="무선인터넷"/>
</bean>
<bean id="
통화방법" class="3G"/>
<bean id="
무선인터넷" class="WiFi"/>

예를 들어 나 같은 경우는
블랙잭을 쓰고 있어서 핸드폰 빈에 블랙잭이라고 설정하고 3GWiFi를 구현한 빈을 핸드폰 빈에 삽입하였다.

그런데 내가 핸드폰을
햅틱으로 바꿨고 햅틱3G와이브로를 지원한다고 하면 다음과 같이 빈 설정을 바꿀수가 있다.

<bean id="핸드폰" class="햅틱"> <- 핸드폰 빈을 '햅틱'으로 바꾼다.
    <property name="통화방법" ref="통화방법"/>
    <property name="무선인터넷 ref="무선인터넷"/>
</bean>
<bean id="
통화방법" class="3G"/>
<bean id="
무선인터넷" class="와이브로"/> <- '와이브로' 클래스 여기만 교체하면 된다.

이런식으로 핸드폰, 통화방법, 무선인터넷 가족으로 묶인 클래스들을 스프링 IoC 기능을 이용하여 쉽게 교체 할 수 있기 때문에 확장성이 높고 유지보수가 편리하다는 것이다.


+ 마치며

프로그래머가 아닌 지인들이 보면 딱딱한 문서 보듯 싫어할 것임에도 불구하고 프로그래밍 관련 글을 쓰기 시작한것은, 블로그 통해서도 프로그래밍 공부를 할 수가 있다고 기대했기 때문입니다. 특히 이번 포스팅에서 프로그래밍 공부를 제대로 했습니다. 객체지향 프로그래밍 같은 경우 고도의 추상화 능력이 요구되는데, 깊이 있는 생각이 요구되는 질문을 이렇게 정리하면서 추상화 능력도 같이 키우는 것이죠.

다만 이번에 정리한 내용은 제 경험속에 있는 지식들을 정리한 것이라 내용이 부족할 수도 있습니다. 다시 한번 고수개발자 분 들의 값진 조언을 듣고 싶습니다. 객체지향에 관한 수많은 재야 고수들이 계실것인데 값진 한마디 부탁드립니다.

사실은 너무 대답하기 어려운 질문들이라 미루고 미뤘는데 드디어 마무리 짓게 됐어요. 이렇게 후련한 포스팅도 드물 것 같습니다.


덧1) 산골 블로그의 관련글
팀원에게 객제지향 개발을 유도하기 (1/3)
팀원에게 객제지향 개발을 유도하기 (2/3)

에러 잡는 마음가짐
개발자와 프로그래밍의 가치을 높여주는 JUnit

추상화의 고수가 되자. (생각의 탄생)
객체지향 글쓰기 (글쓰기 프로그래밍이 가능할까?)

한국스프링사용자모임2회(KSUG) 참가 후기 (스프링 달인의 한수 가르침)
한국스프링사용자모임3회(KSUG) 참가 후기 (자리잡은 커뮤니티)
한국스프링사용자모임4회(KSUG) 참가 후기 (AOP)
한국스프링사용자모임5회(KSUG) 참가 후기 (웹플로우(WebFlow), 보안(Acegi))

덧2) IBM developerWorks의 관련글


Spring MVC에 대한 좋은 기사가 있습니다. 저는 과거에 스트럿츠를 써보고 지금은 Spring MVC를 쓰고 있는데 Spring MVC가 좀더 깔끔하고 실용적이라는 느낌이 들더군요. 깔끔하고 실용적인 Spring MVC와 관련된 자세한 기사가 있으니 읽어보시기 바랍니다.