마소....
http://www.imaso.co.kr/?doc=bbs/gnuboard_pdf.php&bo_table=article&page=1&wr_id=1154&publishdate=20021201
왜 객체지향 프로그래밍을 하는지는 코딩을 밤새도록 많이 해본 개발자라면 충분히 느낄 수 있을 것입니다. 특히 초보자일수록 자바 API의 메쏘드 사용법과 로직 구현에만 급급해 하나의 클래스 안에 다량의 코드를 넣어 프로그래밍하기 일쑤입니다. 또한 매일 하는 일이 코드를, 키를 누르면서 복사하고 붙이기의 반복이고, 코드도 계속 여기저기 뜯어 고쳐서 누더기 같은 코드가 돼버립니다. 이 때문에 사용한 코드를 조금만 고치면 다른 곳에 재사용할 수 있도록 하기 위해서 객체지향 프로그래밍의 기법을 도입하게 됩니다. 이를 위해서는 클래스간의 관계를 잘 설정해야 하는데, 이번 연재에서는 객체지향 프로그램의 꽃인 클래스를 디자인하는 방법 즉, 디자인 패턴과 디자인 패턴을 표현하는 UML 기호에 대해서 설명하겠습니다.
UML의 개념
UML(Unified Modeling Langua ge)은 객체 관련 표준화기구인 OMG에서 1997년 11월에 만든 통합 모델링 언어로 객체지향적 분석 설계 방법론의 표준이라고 할 수 있습니다. 모델링 언어는 쉽게 얘기하자면 음악 연주시 악보에 각종 기호를 표기하는 방법에 비유할 수 있습니다. 악보에 기호를 표기하여 각종 악기 연주자가 악보에 쓰인 기호대로 연주함으로써 음악이 나오듯 UML은 소프트웨어 개발에 있어 클래스의 관계를 표시하기 위한 기호를 비롯해 객체지향 분석 설계를 하기 위한 다양한 방법(유즈케이스 다이어그램, 클래스 다이어그램 등 여러 가지 다이어그램 및 소프트웨어 분석 및 설계 장치)을 제공합니다. 또한 소프트웨어 개발 과정의 산출물을 비주얼하게 제공하고 개발자들과 고객 또는 개발자들 간의 의사소통을 원활하게 할 수 있도록 하고 있습니다.
UML을 처음 접하는 사람이 오해하기 쉬운 것은 UML은 소프트웨어 설계를 위한 도구일 뿐이지 방법은 아니라는 점입니다. 즉 UML을 이용해서 소프트웨어를 개발하는 다양한 방법이 나와 있다는 얘기입니다. 그중 UML을 가장 잘 적용할 수 있는 소프트웨어 개발 프로세스는 1998년 11월 미국 래쇼날에서 개발한 통합 프로세스(Unified Process) 5.0입니다.
이번 호에서는 UML 중에서 디자인 패턴을 이해하기 위해 UML로 표현한 클래스 및 클래스 관계 기호와 프로그램이 시간에 따라 어떻게 작동하는지를 보여주는 시퀀스 다이어그램을 설명하도록 하겠습니다.
클래스의 표현
<그림 1>을 보면 UML에서 클래스는 사각형으로 표시됩니다. 즉, 하나의 사각형은 클래스 하나를 나타냅니다. 클래스는 알다시피 멤버변수와 메쏘드로 구성됩니다. 이것은 <그림 1>처럼 클래스를 표현하는 사각형을 3등분해서 제일 위에는 클래스명, 그 아래에는 멤버변수, 그 다음에는 메쏘드가 옵니다. 여기서 용어를 하나 짚고 넘어가자면 클래스의 멤버변수와 메쏘드는 UML에서는 애트리뷰트와 오퍼레이션으로 칭한다는 것을 알아두길 바랍니다.
또한 클래스명이나 메쏘드명이 이탤릭체로 되어 있으면 각기 추상 클래스나 추상 메쏘드입니다. 그리고 멤버변수와 메쏘드에 밑줄이 그어져 있으면 각기 static 변수, static 메쏘드입니다.
<그림 2>를 보면 접근제한자에 대해 파악할 수 있습니다. ‘+’는 public을 뜻하며, ‘-’는 private, ‘#’은 protected입니다.
클래스의 관계
UML에서 클래스간의 관계는 상속, 인터페이스 구현, 집약, 클래스 사용 등이 있으며 이는 클래스간을 화살표로 연결하여 나타냅니다.
상속
<그림 1>에서 안이 비어 있는 삼각형 머리에 실선으로 된 화살표는 클래스간 상속관계를 나타냅니다. 화살을 맞는 클래스(ParentClass)가 부모 클래스이며 화살을 쏘는 클래스(ChildClass)가 자식 클래스입니다. 자식이 쏜 화살에 부모가 맞았다고 생각하면서 클래스의 상속관계를 이해하기 바랍니다.
인터페이스 구현
<그림 3>을 보면 안이 비어 있는 삼각형이 있는데, 점선으로 된 화살표는 인터페이스 구현관계를 나타냅니다. 화살을 맞는 클래스(MyInterface)가 인터페이스이며 화살을 쏘는 클래스(MyClass)가 인터페이스를 구현하는 클래스입니다.
집약
집약관계(Aggregation)는 용어가 약간 생소할지 모르겠습니다만 코딩하다 보면 자주 나오는 형태입니다. <그림 4>에서 보듯이 간단하게 얘기하면, Cart라는 클래스에서 FoodItem이라는 클래스를 멤버변수로 해서 사용하는 관계입니다. 이것은 다이어몬드와 ‘>’ 모양의 화살촉으로 구성돼 있으며 포함하고 있는 클래스쪽(Cart)이 다이아몬드이며 포함되는 클래스(Food Item)가 화살을 맞습니다.
클래스의 사용관계
클래스 사용관계는 그림처럼 사용하는 클래스로부터 이용당하는 클래스가 ‘->’모양을 화살을 맞는 관계입니다. 이때 화살표 위에 “Uses ▶”처럼 어떻게 사용하는지를 기술해 줍니다. <그림 5>에서 위의 것은 ‘Customer가 Money를 인출한다’라는 의미를 가지고 아래 것은 ‘Factory가 Product를 생성한다’라는 관계입니다.
디자인 패턴의 개념
디자인 패턴(Design Pattern)은 한두 번 들어본 이도 있겠지만 자바를 처음 배우는 독자에겐 생소하리라 생각합니다. 디자인 패턴은 중국무술에 나오는 소림권법에 비유할 수 있습니다. 즉 무술의 고수들이 가장 효율적으로 공격하고 방어하는 각종 손발동작을 묶어서 쓰는 방법이 권법이라면, 자바의 고수들이 클래스들을 가장 효율적이고 짜임새 있게 구성하여 쓰는 방법이 바로 디자인 패턴입니다. 소림권법에도 당랑권, 용권, 호권, 영춘권 등이 있듯이 디자인 패턴에도 싱글톤 패턴, 퍼사드 패턴, 커맨드 패턴 등 여러 가지 정형화된 패턴이 있습니다. 또한 고수들의 권법을 다양한 그림으로 표현하여 책으로 엮은 무공비급이 있습니다. 무공비급에 권법동작을 설명한 그림처럼 디자인 패턴도 클래스간의 관계를 표현하기 위해 UML의 그림과 기호를 사용합니다.
디자인 패턴의 이해
디자인 패턴은 ‘관계’를 이해하는 것이 중요합니다. 쉽게 얘기해 남자와 여자라는 클래스가 있는데 그 남자와 여자가 누구인지를 파악하는 것이 아니라 그 남자와 여자가 연인인지 부부 혹은 선후배인지를 파악하는 것이 바로 패턴입니다.
또한 클래스 설계시 단 한 가지만의 패턴이 적용되지 않습니다. 좀전에 예를 든 경우를 보면 그 사람들이 대학선후배였는데 결혼했다면 부부관계이면서 대학 선후배관계라 볼 수 있습니다. 마찬가지로 그 클래스 사이에서도 다양한 패턴을 발견할 수가 있습니다. 그러면 지금부터 이처럼 다양한 디자인 패턴을 하나씩 살펴볼까요.
싱글톤 패턴
싱글톤(Singleton) 패턴은 해당 패턴이 적용된 클래스의 인스턴스를 하나만 만들어 쓰겠다는 것입니다. 일반적으로 객체는 생성자가 호출될 때 새로운 인스턴스를 만들게 되는데, 일련번호 생성 클래스의 경우 여러 개의 인스턴스가 있으면 일련번호가 꼬이게 됩니다. 이 때문에 인스턴스를 단 하나만 만들어서 서비스하도록 하는 데 적용하는 것이 싱글톤 패턴입니다.
<리스트 6>을 보면 Singleton이라는 클래스에서 getInstance라는 메쏘드를 통해서만 Singleton의 인스턴스를 리턴합니다. 이 때 리턴되는 값은 초기에 static으로 생성된 자신의 인스턴스입니다. static이기 때문에 1개의 값밖에 못가지므로 싱글톤 패턴이 되는 것입니다. 그래서 Singleton 클래스에서 Singleton의 getInstance 메쏘드를 호출해서 얻은 인스턴스는 언제나 똑같게 되는 것입니다.
템플릿 메쏘드 패턴
템플릿 메쏘드(Template Method) 패턴은 상위 클래스에서 어떻게 처리할지만 기술하고 하위 클래스에서 구체적으로 실행하는 코드를 넣는 것입니다. 이는 윗사람이 아랫사람에게 청소를 하라는 행위를 지시하면 아랫사람은 구체적으로 비로 쓸거나 걸레로 닦는 등 구체적인 청소를 하게 되는 것입니다.
<리스트 7>의 추상 클래스인 Connect 클래스에서는 DB와 연결하는 클래스라 보고 connect라는 메쏘드가 추상 메쏘드로 돼 있습니다. 그리고 하위 클래스에 실제 DB는 제품별로 connect라는 메쏘드를 구현했습니다. 이때 주의할 점은 TemplateMethodTest 클래스에서 AConnect, BConnect의 인스턴스를 생성할 때 Connect형으로 생성하여 Connect 클래스에 기술된 메쏘드를 호출한다는 것입니다.
어댑터 패턴
어댑터(Adapter) 패턴은 쓰고 싶은 클래스를 자기에 맞게 변형해서 적용한다는 개념입니다. 어댑터는 가전제품에서 따온 개념인데, 보통 워크맨 제품의 경우 3V 직류제품은 220V 교류전원을 바로 쓸 수 없기 때문에 3V 교류로 바꿔주는 어댑터를 꽂아서 씁니다.
<리스트 8>의 예를 보면 Format이라는 클래스를 구현해야 하는데, MyCalendarFormat이 Format을 상속받아서 MyCalendar에 맞게 구현하고 있습니다. 그리하여 AdapterTest에서는 MyCalendar 및 Format이 합쳐진 기능을 사용할 수 있습니다. 즉 특정 클래스의 메쏘드를 사용할 때 바로 쓰기는 뭐하고 적절히 바꿔서 가져와야 할 경우 어댑터 패턴을 적용하면 되겠습니다.
퍼사드 패턴
퍼사드(Facade) 패턴은 영화예매 창구로 보면 됩니다. 우리가 예매할 때 영화제목과 시간을 말해주면 창구에서는 해당 시간의 영화가 잔여좌석이 있는지를 확인하고 금액을 알려 줍니다. 영화표를 예매하는 사람은 창구에서 일어나는 일은 알 수 없고 다만 창구를 통해서 표를 예매할 수 있다는 것만 압니다.
<리스트 9>의 예를 보면 데이터파일에서 데이터를 불러와서 간단한 XML 태그를 만들려고 하는데, FacadeTest에서는 데이터를 파싱하고 XML 태그를 생성하는 메쏘드를 만들지 않고 바로 InfoBox의 makeTag를 호출합니다. InfoBox가 영화예매 창구 역할을 한다고 보면 되겠습니다. InfoBox에서는 Data Parser와 TagMaker의 적절한 메쏘드를 호출하고 있습니다.
브리지 패턴
<그림 10>에서 브리지(Bridge) 패턴은 다리 교각처럼 생겼는데, 한쪽 다리의 클래스 상속 계층은 기능 측면이고 다른 한쪽은 그 기능을 층층이 구현한 클래스 상속 계층이라 보면 됩니다. 즉 기능을 추가하려고 할 때는 좌측에 클래스를 상속해서 새로운 메쏘드 정의를 넣어 줍니다. 그리고 구현의 추가는 우측의 클래스를 상속해서 새로운 기능 구현을 넣어줍니다. 이렇게 기능과 구현이 분리되어 있기 때문에 코드가 복잡해지지 않고 원하는 기능과 구현을 계속 추가해 나갈 수 있습니다.
그밖의 디자인 패턴
지금까지 소개한 패턴 외에 많은 패턴들이 있습니다. 그러나 본 연재에서는 앞의 5가지만 다루고 기타 패턴은 각종 디자인 패턴 관련 책을 참조하세요. 기타 패턴에는 Abstract Factory, Builder, Chain of Responsibility, Command, Composite, Decorator, Factory Method, Flyweight, Interpreter, Iterator, Mediator, Memento, Observer, Prototype, Proxy, State, Strategy, Visitor 등이 있습니다.
나머지는 스스로 찾아낼 수 있겠죠?
여러분 그동안 감사했고 수고 많았습니다. 처음 원고를 쓸 때는 6개월이 아득하고 길게만 느껴졌는데 벌써 마지막이라니 시간은 정말 짧은 것 같습니다. 항상 원고를 쓰고 나면 이 부분을 더 설명했으면 하는 아쉬움이 늘 남습니다. 무엇보다도 여러분께 제일 강조하고 싶은 것은 ‘이것은 이것이고 저것은 저것이다’하는 지식의 전달이 아니라 ‘이것은 이렇게 찾아내고 저것은 저렇게 찾아내어야 한다’라는 것입니다. 제가 설명하지 못한 부분은 여러분 스스로 다양한 방법으로 찾아내고 자기의 지식으로 소화해내는 것이 중요합니다. 아무쪼록 여러분의 앞날에 행운이 가득하길 바랍니다.
정리 : 이종림 nowhere@korea.cnet.com
1회 2002.7 | 어떻게 자바를 나의 무공으로 만들 것인가
2회 2002.8 | 자바의 기본 문법과 클래스 살펴보기
3회 2002.9 | 에러를 잡아라
4회 2002.10 | 자바 제대로 프로그래밍하기
5회 2002.11 | 자바를 더 빠르게 만들자
6회 2002.12 | 객체지향적으로 자바 프로그래밍하기
개념을 확실히 이해했나요?
다음과 같이 지금까지 배운 것을 개념을 확인하는 프로그램을 만들어 보세요.
? 실제 프로젝트시 데이터베이스에 연결하는 데 시간이 많이 걸려서 미리 연결해둔 커넥션 객체를 모아서(커넥션풀) 관리합니다. 이때 이 커녁션풀을 관리하는 클래스는 기본적으로 무슨 패턴을 써서 만들어야 할까요?
? 앞의 퍼사드 패턴의 예제는 완벽한 XML 파일을 만들지 못합니다. 클래스나 메쏘드를 추가해서 완벽한 XML 파일을 만들어 보세요(이때 어느 클래스를 수정해야 하는지 파악한다면 퍼사드 패턴을 제대로 이해하고 있는 것입니다).
http://www.imaso.co.kr/?doc=bbs/gnuboard_pdf.php&bo_table=article&page=1&wr_id=1154&publishdate=20021201
왜 객체지향 프로그래밍을 하는지는 코딩을 밤새도록 많이 해본 개발자라면 충분히 느낄 수 있을 것입니다. 특히 초보자일수록 자바 API의 메쏘드 사용법과 로직 구현에만 급급해 하나의 클래스 안에 다량의 코드를 넣어 프로그래밍하기 일쑤입니다. 또한 매일 하는 일이 코드를
UML의 개념
UML(Unified Modeling Langua ge)은 객체 관련 표준화기구인 OMG에서 1997년 11월에 만든 통합 모델링 언어로 객체지향적 분석 설계 방법론의 표준이라고 할 수 있습니다. 모델링 언어는 쉽게 얘기하자면 음악 연주시 악보에 각종 기호를 표기하는 방법에 비유할 수 있습니다. 악보에 기호를 표기하여 각종 악기 연주자가 악보에 쓰인 기호대로 연주함으로써 음악이 나오듯 UML은 소프트웨어 개발에 있어 클래스의 관계를 표시하기 위한 기호를 비롯해 객체지향 분석 설계를 하기 위한 다양한 방법(유즈케이스 다이어그램, 클래스 다이어그램 등 여러 가지 다이어그램 및 소프트웨어 분석 및 설계 장치)을 제공합니다. 또한 소프트웨어 개발 과정의 산출물을 비주얼하게 제공하고 개발자들과 고객 또는 개발자들 간의 의사소통을 원활하게 할 수 있도록 하고 있습니다.
UML을 처음 접하는 사람이 오해하기 쉬운 것은 UML은 소프트웨어 설계를 위한 도구일 뿐이지 방법은 아니라는 점입니다. 즉 UML을 이용해서 소프트웨어를 개발하는 다양한 방법이 나와 있다는 얘기입니다. 그중 UML을 가장 잘 적용할 수 있는 소프트웨어 개발 프로세스는 1998년 11월 미국 래쇼날에서 개발한 통합 프로세스(Unified Process) 5.0입니다.
이번 호에서는 UML 중에서 디자인 패턴을 이해하기 위해 UML로 표현한 클래스 및 클래스 관계 기호와 프로그램이 시간에 따라 어떻게 작동하는지를 보여주는 시퀀스 다이어그램을 설명하도록 하겠습니다.
클래스의 표현
<그림 1>을 보면 UML에서 클래스는 사각형으로 표시됩니다. 즉, 하나의 사각형은 클래스 하나를 나타냅니다. 클래스는 알다시피 멤버변수와 메쏘드로 구성됩니다. 이것은 <그림 1>처럼 클래스를 표현하는 사각형을 3등분해서 제일 위에는 클래스명, 그 아래에는 멤버변수, 그 다음에는 메쏘드가 옵니다. 여기서 용어를 하나 짚고 넘어가자면 클래스의 멤버변수와 메쏘드는 UML에서는 애트리뷰트와 오퍼레이션으로 칭한다는 것을 알아두길 바랍니다.
또한 클래스명이나 메쏘드명이 이탤릭체로 되어 있으면 각기 추상 클래스나 추상 메쏘드입니다. 그리고 멤버변수와 메쏘드에 밑줄이 그어져 있으면 각기 static 변수, static 메쏘드입니다.
<그림 2>를 보면 접근제한자에 대해 파악할 수 있습니다. ‘+’는 public을 뜻하며, ‘-’는 private, ‘#’은 protected입니다.
클래스의 관계
UML에서 클래스간의 관계는 상속, 인터페이스 구현, 집약, 클래스 사용 등이 있으며 이는 클래스간을 화살표로 연결하여 나타냅니다.
상속
<그림 1>에서 안이 비어 있는 삼각형 머리에 실선으로 된 화살표는 클래스간 상속관계를 나타냅니다. 화살을 맞는 클래스(ParentClass)가 부모 클래스이며 화살을 쏘는 클래스(ChildClass)가 자식 클래스입니다. 자식이 쏜 화살에 부모가 맞았다고 생각하면서 클래스의 상속관계를 이해하기 바랍니다.
인터페이스 구현
<그림 3>을 보면 안이 비어 있는 삼각형이 있는데, 점선으로 된 화살표는 인터페이스 구현관계를 나타냅니다. 화살을 맞는 클래스(MyInterface)가 인터페이스이며 화살을 쏘는 클래스(MyClass)가 인터페이스를 구현하는 클래스입니다.
집약
집약관계(Aggregation)는 용어가 약간 생소할지 모르겠습니다만 코딩하다 보면 자주 나오는 형태입니다. <그림 4>에서 보듯이 간단하게 얘기하면, Cart라는 클래스에서 FoodItem이라는 클래스를 멤버변수로 해서 사용하는 관계입니다. 이것은 다이어몬드와 ‘>’ 모양의 화살촉으로 구성돼 있으며 포함하고 있는 클래스쪽(Cart)이 다이아몬드이며 포함되는 클래스(Food Item)가 화살을 맞습니다.
클래스의 사용관계
클래스 사용관계는 그림처럼 사용하는 클래스로부터 이용당하는 클래스가 ‘->’모양을 화살을 맞는 관계입니다. 이때 화살표 위에 “Uses ▶”처럼 어떻게 사용하는지를 기술해 줍니다. <그림 5>에서 위의 것은 ‘Customer가 Money를 인출한다’라는 의미를 가지고 아래 것은 ‘Factory가 Product를 생성한다’라는 관계입니다.
디자인 패턴의 개념
디자인 패턴(Design Pattern)은 한두 번 들어본 이도 있겠지만 자바를 처음 배우는 독자에겐 생소하리라 생각합니다. 디자인 패턴은 중국무술에 나오는 소림권법에 비유할 수 있습니다. 즉 무술의 고수들이 가장 효율적으로 공격하고 방어하는 각종 손발동작을 묶어서 쓰는 방법이 권법이라면, 자바의 고수들이 클래스들을 가장 효율적이고 짜임새 있게 구성하여 쓰는 방법이 바로 디자인 패턴입니다. 소림권법에도 당랑권, 용권, 호권, 영춘권 등이 있듯이 디자인 패턴에도 싱글톤 패턴, 퍼사드 패턴, 커맨드 패턴 등 여러 가지 정형화된 패턴이 있습니다. 또한 고수들의 권법을 다양한 그림으로 표현하여 책으로 엮은 무공비급이 있습니다. 무공비급에 권법동작을 설명한 그림처럼 디자인 패턴도 클래스간의 관계를 표현하기 위해 UML의 그림과 기호를 사용합니다.
디자인 패턴의 이해
디자인 패턴은 ‘관계’를 이해하는 것이 중요합니다. 쉽게 얘기해 남자와 여자라는 클래스가 있는데 그 남자와 여자가 누구인지를 파악하는 것이 아니라 그 남자와 여자가 연인인지 부부 혹은 선후배인지를 파악하는 것이 바로 패턴입니다.
또한 클래스 설계시 단 한 가지만의 패턴이 적용되지 않습니다. 좀전에 예를 든 경우를 보면 그 사람들이 대학선후배였는데 결혼했다면 부부관계이면서 대학 선후배관계라 볼 수 있습니다. 마찬가지로 그 클래스 사이에서도 다양한 패턴을 발견할 수가 있습니다. 그러면 지금부터 이처럼 다양한 디자인 패턴을 하나씩 살펴볼까요.
싱글톤 패턴
싱글톤(Singleton) 패턴은 해당 패턴이 적용된 클래스의 인스턴스를 하나만 만들어 쓰겠다는 것입니다. 일반적으로 객체는 생성자가 호출될 때 새로운 인스턴스를 만들게 되는데, 일련번호 생성 클래스의 경우 여러 개의 인스턴스가 있으면 일련번호가 꼬이게 됩니다. 이 때문에 인스턴스를 단 하나만 만들어서 서비스하도록 하는 데 적용하는 것이 싱글톤 패턴입니다.
<리스트 6>을 보면 Singleton이라는 클래스에서 getInstance라는 메쏘드를 통해서만 Singleton의 인스턴스를 리턴합니다. 이 때 리턴되는 값은 초기에 static으로 생성된 자신의 인스턴스입니다. static이기 때문에 1개의 값밖에 못가지므로 싱글톤 패턴이 되는 것입니다. 그래서 Singleton 클래스에서 Singleton의 getInstance 메쏘드를 호출해서 얻은 인스턴스는 언제나 똑같게 되는 것입니다.
템플릿 메쏘드 패턴
템플릿 메쏘드(Template Method) 패턴은 상위 클래스에서 어떻게 처리할지만 기술하고 하위 클래스에서 구체적으로 실행하는 코드를 넣는 것입니다. 이는 윗사람이 아랫사람에게 청소를 하라는 행위를 지시하면 아랫사람은 구체적으로 비로 쓸거나 걸레로 닦는 등 구체적인 청소를 하게 되는 것입니다.
<리스트 7>의 추상 클래스인 Connect 클래스에서는 DB와 연결하는 클래스라 보고 connect라는 메쏘드가 추상 메쏘드로 돼 있습니다. 그리고 하위 클래스에 실제 DB는 제품별로 connect라는 메쏘드를 구현했습니다. 이때 주의할 점은 TemplateMethodTest 클래스에서 AConnect, BConnect의 인스턴스를 생성할 때 Connect형으로 생성하여 Connect 클래스에 기술된 메쏘드를 호출한다는 것입니다.
어댑터 패턴
어댑터(Adapter) 패턴은 쓰고 싶은 클래스를 자기에 맞게 변형해서 적용한다는 개념입니다. 어댑터는 가전제품에서 따온 개념인데, 보통 워크맨 제품의 경우 3V 직류제품은 220V 교류전원을 바로 쓸 수 없기 때문에 3V 교류로 바꿔주는 어댑터를 꽂아서 씁니다.
<리스트 8>의 예를 보면 Format이라는 클래스를 구현해야 하는데, MyCalendarFormat이 Format을 상속받아서 MyCalendar에 맞게 구현하고 있습니다. 그리하여 AdapterTest에서는 MyCalendar 및 Format이 합쳐진 기능을 사용할 수 있습니다. 즉 특정 클래스의 메쏘드를 사용할 때 바로 쓰기는 뭐하고 적절히 바꿔서 가져와야 할 경우 어댑터 패턴을 적용하면 되겠습니다.
퍼사드 패턴
퍼사드(Facade) 패턴은 영화예매 창구로 보면 됩니다. 우리가 예매할 때 영화제목과 시간을 말해주면 창구에서는 해당 시간의 영화가 잔여좌석이 있는지를 확인하고 금액을 알려 줍니다. 영화표를 예매하는 사람은 창구에서 일어나는 일은 알 수 없고 다만 창구를 통해서 표를 예매할 수 있다는 것만 압니다.
<리스트 9>의 예를 보면 데이터파일에서 데이터를 불러와서 간단한 XML 태그를 만들려고 하는데, FacadeTest에서는 데이터를 파싱하고 XML 태그를 생성하는 메쏘드를 만들지 않고 바로 InfoBox의 makeTag를 호출합니다. InfoBox가 영화예매 창구 역할을 한다고 보면 되겠습니다. InfoBox에서는 Data Parser와 TagMaker의 적절한 메쏘드를 호출하고 있습니다.
브리지 패턴
<그림 10>에서 브리지(Bridge) 패턴은 다리 교각처럼 생겼는데, 한쪽 다리의 클래스 상속 계층은 기능 측면이고 다른 한쪽은 그 기능을 층층이 구현한 클래스 상속 계층이라 보면 됩니다. 즉 기능을 추가하려고 할 때는 좌측에 클래스를 상속해서 새로운 메쏘드 정의를 넣어 줍니다. 그리고 구현의 추가는 우측의 클래스를 상속해서 새로운 기능 구현을 넣어줍니다. 이렇게 기능과 구현이 분리되어 있기 때문에 코드가 복잡해지지 않고 원하는 기능과 구현을 계속 추가해 나갈 수 있습니다.
그밖의 디자인 패턴
지금까지 소개한 패턴 외에 많은 패턴들이 있습니다. 그러나 본 연재에서는 앞의 5가지만 다루고 기타 패턴은 각종 디자인 패턴 관련 책을 참조하세요. 기타 패턴에는 Abstract Factory, Builder, Chain of Responsibility, Command, Composite, Decorator, Factory Method, Flyweight, Interpreter, Iterator, Mediator, Memento, Observer, Prototype, Proxy, State, Strategy, Visitor 등이 있습니다.
나머지는 스스로 찾아낼 수 있겠죠?
여러분 그동안 감사했고 수고 많았습니다. 처음 원고를 쓸 때는 6개월이 아득하고 길게만 느껴졌는데 벌써 마지막이라니 시간은 정말 짧은 것 같습니다. 항상 원고를 쓰고 나면 이 부분을 더 설명했으면 하는 아쉬움이 늘 남습니다. 무엇보다도 여러분께 제일 강조하고 싶은 것은 ‘이것은 이것이고 저것은 저것이다’하는 지식의 전달이 아니라 ‘이것은 이렇게 찾아내고 저것은 저렇게 찾아내어야 한다’라는 것입니다. 제가 설명하지 못한 부분은 여러분 스스로 다양한 방법으로 찾아내고 자기의 지식으로 소화해내는 것이 중요합니다. 아무쪼록 여러분의 앞날에 행운이 가득하길 바랍니다.
정리 : 이종림 nowhere@korea.cnet.com
1회 2002.7 | 어떻게 자바를 나의 무공으로 만들 것인가
2회 2002.8 | 자바의 기본 문법과 클래스 살펴보기
3회 2002.9 | 에러를 잡아라
4회 2002.10 | 자바 제대로 프로그래밍하기
5회 2002.11 | 자바를 더 빠르게 만들자
6회 2002.12 | 객체지향적으로 자바 프로그래밍하기
개념을 확실히 이해했나요?
다음과 같이 지금까지 배운 것을 개념을 확인하는 프로그램을 만들어 보세요.
? 실제 프로젝트시 데이터베이스에 연결하는 데 시간이 많이 걸려서 미리 연결해둔 커넥션 객체를 모아서(커넥션풀) 관리합니다. 이때 이 커녁션풀을 관리하는 클래스는 기본적으로 무슨 패턴을 써서 만들어야 할까요?
? 앞의 퍼사드 패턴의 예제는 완벽한 XML 파일을 만들지 못합니다. 클래스나 메쏘드를 추가해서 완벽한 XML 파일을 만들어 보세요(이때 어느 클래스를 수정해야 하는지 파악한다면 퍼사드 패턴을 제대로 이해하고 있는 것입니다).
