디자인패턴 공부하는 팁~

[Java 언어로 배우는 디자인 패턴 입문]을 보면서 이 책을 읽는 내내 하나의 화두로 가져가야 할 사항인 것 같아 다시금 정리하는 의미로 옮겨 적는다. 각각의 디자인 패턴을 이해하기 위한 힌트들로 항시 디자인 패턴을 접하면서 머리속에서 하나씩 떠올려 본다면 패턴을 이해하는데 보다 많은 도움을 얻을 수 있으리라 생각된다. ■ 디자인 패턴은 클래스 라이브러리가 아닙니다. 우리들이 자바로 프로그램을 작성할 때 클래스들이 모여있는 클래스 라이브러리를 이용합니다. 그러나 디자인 패턴은 클래스 라이브러리는 아닙니다. 디자인 패턴은 클래스 라이브러리보다 일반적인 개념입니다. 클래스 라이브러리는 부품이 되는 프로그램이지만, 디자인 패턴은 부품이 어떻게 조립되어있고, 각각의 부품이 어떻게 연관되어 커다란 기능을 완수하는지를 표현합니다. 백설공주 얘기를 예로 들어 생각해봅시다. 어느 특정 연극에서 백설공주 역할을 누가 연기했는지 일반적인 백설공주 이야기의 줄거리를 설명할 때에는 필수사항이 아닙니다. 구체적인 배우를 설명하기 보다는 백설공주와 왕자 사이의 '관계'를 설명하는 것이 중요하겠지요. 특정한 배우가 연기한 특정한 연극만이 '백설공주'가 아니라 누가 연기를 하더라도 백설공주의 줄거리를 따르고 있으면 그것은 백설공주의 이야기가 됩니다. 즉, 배우들이 연기하는 역할이 가장 중요합니다. 디자인 패턴도 마찬가지입니다. "Abstract Factory 패턴은 어떤 것입니까?"라는 질문에 대답할 때 구체적인 프로그램의 예제를 읽는 것도 이해하는데 도움이 되지만, 특정 프로그램만이 Abstract Factory패턴이 아닙니다. 중요한 것은 어떤 종류의 클래스와 인스턴스가 등장하여 서로 어떻게 관련되어 있는가 하는 점입니다. ■ 그러나 클래스 라이브러리 안에서 디자인 패턴이 사용됩니다. 디자인 패턴이 클래스 라이브러리는 아닙니다. 그러나 자바의 표준적인 클래스 라이브러리안에서 디자인 패턴이 활용되는 클래스가 있습니다. 디자인 패턴을 알고 있으면 클래스 라이브러리의 역할을 이해하는데 도움이 됩니다. 각 디자인 패턴의 장에서 설명하겠지만, 다음은 전형적인 예입니다. - java.util.Iterator는 여러 개를 열거할 때에 사용하는 클래스입니다. 여기서는 Iterator패턴이 사용되고 있습니다. - java.util.Observer는 객체의 상태변화를 관찰하는 인터페이스입니다. 여기서는 Observer패턴이 사용되고 있습니다. - 다음의 메소드에서는 Factory Method 패턴이 사용되고 있습니다.   :java.util.Calendar 클래스의 getInstance 메소드   :java.security.SecureRandom 클래스의 getInstance 메소드   :java.text.NumberFormat 클래스의 getInstance 메소드 - java.awt.Component와 java.awt.Container라는 클래스에서는 Composite 패턴이 사용되고 있습니다. ■ 프로그램을 완성품으로 보지 않습니다. 디자인 패턴의 목표 중의 하나는 프로그램을 재사용할 수 있도록 만드는 것입니다. 프로그램을 어떻게 '부품'으로서 재사용할지 고려해야 합니다. 따라서 프로그램의 예제를 '완성품'으로 생각하지말고 앞으로 '기능을 확장'해 나가고 '변경'해 나갈 수 있는 것으로 생각해 주십시오. - 어떤 기능을 확장할 수 있는가? - 기능을 확장할 때 수정이 필요한 것은 어느 클래스인가? - 수정이 필요하지 않은 것은 어떤 클래스인가? 이와 같은 관점에서 디자인 패턴을 바라보면 이해가 깊어질 것입니다. ■ 다이어그램은 보는 것이 아니라 읽는 것입니다. 디자인 패턴을 해설할 때 클래스 다이어그램과 시퀀스 다이어그램이 등장합니다. 이 다이어그램들을 단순한 '다이어그램'으로 생각하지 마세요. 클래스 다이어그램이 등장하면 우선 사각형(클래스)을 한 개씩 살펴보고, 그 안에 쓰여있는 메소드명이 보통 메소드인지 추상 메소드인지를 확인합니다. 그리고 나서 클래스간의 화살표를 살펴보면서 어느 클래스가 어느 인터페이스를 구현하고 있는지 확인합니다. 이와 같이 다이어그램 안의 구성요소가 무엇을 의미하고 있는지 꼼꼼히 읽어나가는 동안에 다이어그램 전체를 이해할 수 있게 됩니다. 시퀀스 다이어그램이 클래스 다이어그램에 비해 읽기 편할 것입니다. 시간은 위에서 아래로 흐르기 때문에 차례로 어느 객체가 어느 객체를 호출하는지 하나씩 확인해 나갑니다. 그렇게 하면 패턴 안에서의 각 객체의 역할을 조금씩 이해하게 될 것입니다. 그림을 한번 봐서는 의미를 알 수 없습니다. 꼼꼼히 '읽을' 필요가 있습니다. ■ 스스로 예제를 생각하세요. 단순히 프로그램의 예제를 읽는 것이 아니라 자기 나름대로 예제를 생각해봅시다. 또한 자신이 설계나 프로그래밍을 할 때 이 책에서 배운 디자인 패턴이 적용되지는 않을지 생각해 보는 것도 좋겠지요. ■ 역할을 이해합니다. - 백설공주 역할을 하는 것은 누구인가요? 디자인 패턴은 드라마와 비슷합니다. 클래스나 인터페이스라는 등장 인물들이 서로 연관을 맺으면서 드라마를 만들어 갑니다. 한사람씩 역할이 배당되고 각자 자신의 역할에 맞게 행동합니다. 주인공도 등장하고 연극은 클라이맥스를 향해 갑니다. 디자인 패턴도 마찬가지입니다. 디자인 패턴에 따라 클래스나 인터페이스에게 각각의 역할이 배당됩니다. 각 클래스나 인터페이스의 역할을 이해하지 못하면 드라마 전체의 패턴을 꿰뚫어 볼 수 없어서 제대로 된 형식으로 만들 수 없습니다. 주인공을 악역으로 만들어 버리기도 하고, 코메디인데 비극으로 만들거나, 다큐멘터리인데 지어낸 이야기처럼 만들어 버릴 수도 있습니다. 다음의 각 장에서는 디자인 패턴을 하나씩 소개하면서 패턴에 등장하는 역할도 아울러 소개하겠습니다. 예제를 읽을 때에는 단순히 프로그램으로만 읽지 말고 각 클래스나 인터페이스가 이 패턴에서 어떤 역할을 하고 있는지 주목하면서 읽어 주십시요. 동일한 패턴이라면 클래스 이름이 다르더라도 역할의 대응이 있습니다. 그리고 역할의 대응이 존재하면 이해하기가 쉬워집니다. 구체적인 연기자가 누구이든 상관없이 연극 전체를 간파할 수 있게 될 것입니다. 지금 관람하고 있는 연극이 '백설공주'라면 구체적인 연기자가 누구이든 왕자는 백설공주를 사랑하겠지요. 그리고 연극의 마지막 장면에서 백설공주는 왕자의 키스를 받고 눈을 뜨게 될 것입니다.

원본 : http://blog.paran.com/devtopia/13962641