Design Pattern 카테고리에서는 Design Pattern이란 무엇이며, 현재 개발자들이 많이 사용하고 있는 Design Pattern에 대해서 다뤄볼 것이다. 먼저 Design Pattern들을 소개하기 앞서 Design Pattern 이란 무엇이며, 왜 사용을 해야 하는지 등을 간단히 소개하고 넘어간다.
-- Design Pattern 이란 무엇인가 ?
프로그래밍을 작성할 때 프로그래머라면 누구나가 많은 것을 고민하고 생각하는 것들이 있을 것이다. 수 많은 프로그래머들이 있었고 그들은 유사한 문제점에 대한 해결책 또는 대안을 나름대로 고민하여 해결했을 것이다. 그리고, 다른 프로그래머 또는 잘 만들어진 프로그램의 좋은 소스 코드들을 참조하고 그들이 많은 시간을 들여 구현한 프로그램의 구조를 자신들의 코드에 반영하고 싶어한다.
좋은 코드를 참조하면 좋은 코드를 만들 수 있다는 것은 당연한 진리이다. 그러나, 진정으로 좋은 코드는 쉽게 접할 수가 없고, 접한다고 해도 그 코드를 구조를 파악하고 코드에 담긴 철학을 이해하기에는 너무나 많은 시간이 소비된다. 그러면, 프로그래머들이 서로의 좋은 기법을 참조하고 사용할 방법은 없는 것인가? 객체 지향 프로그래밍에서 가장 중요하게 여겨지는 것이 "코드의 재활용성"에 있음에도 불구하고, 다른 이들의 코드와 구조를 왜 그리도 참고하기 힘든 것인가?
프로그래머가 어떠한 시스템을 개발해야 한다면, 시스템 구현에 있어서 시스템의 구성, 리소스의 처리 등 구현 초기의 사상들을 어떻게 구조화 할 것인가? 구현 후 요구사항의 추가 또는 변경 등이 발생 했을 때 그 부분들을 어떻게 잘 수용할 것인가? 이런 수많은 난제들이 프로그래머들 앞에 도사리고 있는데 대체 어떻게 헤쳐나갈 것 인가?
그건 Design Pattern이 이런 수많은 난제들을 직접적으로 해결해 준다. 시스템의 구현시 구조를 이렇게 가져가면 효과적이면 추후 확장 가능한가에 대한 해답을 클래스 들의 구현방법으로 제시해 준다.
Design Pattern을 공부한다는 것은 훌륭한 프로그래머의 좋은 디자인 형태는 배우는 것이라 생각된다. 프로그래머들이 향후 2~3년후에 시행착오로 알아낼 지식을 Design Pattern을 공부함으로써 그 기간을 앞질러 나갈 수 있는 것이다. 훌륭한 디자인 형태를 공부해 둠으로써 자신의 코드를 좀더 좋게 다듬을 수 있으며, 이러한 자신의 코드들이 모여 전체 시스템의 품질이 향상될 수 있다는 것이다.
Design Pattern의 종류와 구조를 이해하고 암기하는 것은 어려운 일이 아니다. 이것은 시간만 들이면 다 할 수 있는 일이다. 실제로 어려운 일은 프로그래머가 접하는 문제에 자신이 습득한 Design Pattern을 적절하게 적용하는 일이다. Design Pattern이 실제 적용 될 때는 여러 패턴이 혼합되어 적용되며 또한 거의 대부분의 패턴들이 약간씩이나마 변형되어 적용되게 된다. 그리고 꼭 명심해야 할 것은 무리한 패턴의 적용과 잘 못된 패턴의 적용했을 때의 부작용도 항상 염두해 두어야 한다.
-- Design Pattern은 변화 대비
프로그래머가 구현 할 시스템의 요구사항의 변화가 없고, 구현 후 변경사항이 없다면 굳이 Design Pattern을 적용할 필요는 없다. 그러나 실제 개발되는 대부분의 시스템들은 구현 후 긴 기간을 유지보수 기간을 가진다. 요구사항은 개발 후 변경은 말할 것도 없고, 개발기간에도 심없이 변경이 된다. 코딩 중에도 요구사항의 잘 못된 점을 변결하고 변경하야 하는 경우도 발생을 한다. 그래서 프로그래머들은 요구사항의 변화에 익숙해져야 하며, 변화에 대비하여 디자인해야 한다. 프로그래머의 경력은 이런것이 녹아있는 것이 아닌가 싶다. 경험 많은 프로그래머들은 항상 자신의 코드를 추상하하고, 일반적으로 만들려고 노력들을 한다. Design Pattern은 변화에 따른 변경되어야 하는 코드들을 최소화시켜준다. 지금까지 알려진 Design Pattern들을 하나 하나 유심히 보면 모든 Design Pattern의 초점은 "변화"라는 것을 파악할 수 있을 것이다.
-- Design Pattern을 적용할때 중요한 규칙
지금까지 소개 된 Design Pattern을 유심히 보면 공통 된 규칙이 존재한다는 것을 알수있다.
- 구현 클래스가 아닌 추상화 된 인터페이스로 프로그래밍하자.
DataTranslator Object는 EnglishTranslatorImpl을 직접 바라보는 것이 아니라 항상 추상화 된 Translator(Interface)를 통해 보도록 한다. 실제 구현체인 EnglishTranslatorImpl이 변경되더라도 그를 사용하고 있는 Object(DataTranslator)는 영향을 받지 않도록 하기 위해서이다. Interface(Translator)는 가급적 변화되지 않게 일반적으로 추상화를 시켜야 한다.
모든 구현을 Interface를 통할 필요는 없다. 그러나, 복잡한 비즈니스 로직을 담고 있거나, 변경이 잦은 객체인 경우는 Interface를 가져가는 것이 시간이 흐를수록 좋다는 것을 느끼게 될 것이다.
- 상속(Inheritance)이 아니라 Delegation을 사용한다.
상속은 OOP의 기본 개념이다. 그런데 상속을 사용하지 말라는 것은 뭔 말인가? 상속은 공통 된 특징을 Super Class에 정의를 하여 하위 클래스까지 사용을 하게 된다. 그러나 Sub Class 입장에서 보면 불필요한 속성이나 메소드가 단지 Super Class에 존재한다는 사실만으로 접근 가능하게 되어 버리는 경우가 있다. 즉 Sub Class와 Super Class의 구조가 컴파일시에 서로 엮이게 되어 Runtime 시에는 이를 바꿀 수가 없다는 것이다.
Delegation은 Super Class가 내부 필드로 존재하게 되고 필요할 때마다 이 필드에 접근하여 사용하게 된다. 이렇게 되면 Runtime 시에 내부 필드를 자유롭게 바꿀 수 있게 되어 해당 필드를 접근함으로써 얻어지는 행위 또한 바뀌게 된다. 즉 Delegation을 통해 Runtime시의 행위가 바뀌게 되는 것이 최대 이점인 것이다.
- Coupling을 최소화함으로써 추후의 변화를 최소화한다.
어느 하나의 Object의 기능 변화가 전체 클래스 구조를 바꾸거나 혹은 많은 부분에 걸쳐 변화를 야기한다면 뭔가 객체설계가 잘 못 되어진 것이다. 그리고 여러 부분을 중복되서 수정하고 있다면 이 또한 뭔가 잘 못 되었다는 것이다. 모든 디자인 패턴들이 일관되게 말하는 것은 "Coupling을 최소화하라"이다.
-- Design Pattern 이란 무엇인가 ?
프로그래밍을 작성할 때 프로그래머라면 누구나가 많은 것을 고민하고 생각하는 것들이 있을 것이다. 수 많은 프로그래머들이 있었고 그들은 유사한 문제점에 대한 해결책 또는 대안을 나름대로 고민하여 해결했을 것이다. 그리고, 다른 프로그래머 또는 잘 만들어진 프로그램의 좋은 소스 코드들을 참조하고 그들이 많은 시간을 들여 구현한 프로그램의 구조를 자신들의 코드에 반영하고 싶어한다.
좋은 코드를 참조하면 좋은 코드를 만들 수 있다는 것은 당연한 진리이다. 그러나, 진정으로 좋은 코드는 쉽게 접할 수가 없고, 접한다고 해도 그 코드를 구조를 파악하고 코드에 담긴 철학을 이해하기에는 너무나 많은 시간이 소비된다. 그러면, 프로그래머들이 서로의 좋은 기법을 참조하고 사용할 방법은 없는 것인가? 객체 지향 프로그래밍에서 가장 중요하게 여겨지는 것이 "코드의 재활용성"에 있음에도 불구하고, 다른 이들의 코드와 구조를 왜 그리도 참고하기 힘든 것인가?
프로그래머가 어떠한 시스템을 개발해야 한다면, 시스템 구현에 있어서 시스템의 구성, 리소스의 처리 등 구현 초기의 사상들을 어떻게 구조화 할 것인가? 구현 후 요구사항의 추가 또는 변경 등이 발생 했을 때 그 부분들을 어떻게 잘 수용할 것인가? 이런 수많은 난제들이 프로그래머들 앞에 도사리고 있는데 대체 어떻게 헤쳐나갈 것 인가?
그건 Design Pattern이 이런 수많은 난제들을 직접적으로 해결해 준다. 시스템의 구현시 구조를 이렇게 가져가면 효과적이면 추후 확장 가능한가에 대한 해답을 클래스 들의 구현방법으로 제시해 준다.
Design Pattern을 공부한다는 것은 훌륭한 프로그래머의 좋은 디자인 형태는 배우는 것이라 생각된다. 프로그래머들이 향후 2~3년후에 시행착오로 알아낼 지식을 Design Pattern을 공부함으로써 그 기간을 앞질러 나갈 수 있는 것이다. 훌륭한 디자인 형태를 공부해 둠으로써 자신의 코드를 좀더 좋게 다듬을 수 있으며, 이러한 자신의 코드들이 모여 전체 시스템의 품질이 향상될 수 있다는 것이다.
Design Pattern의 종류와 구조를 이해하고 암기하는 것은 어려운 일이 아니다. 이것은 시간만 들이면 다 할 수 있는 일이다. 실제로 어려운 일은 프로그래머가 접하는 문제에 자신이 습득한 Design Pattern을 적절하게 적용하는 일이다. Design Pattern이 실제 적용 될 때는 여러 패턴이 혼합되어 적용되며 또한 거의 대부분의 패턴들이 약간씩이나마 변형되어 적용되게 된다. 그리고 꼭 명심해야 할 것은 무리한 패턴의 적용과 잘 못된 패턴의 적용했을 때의 부작용도 항상 염두해 두어야 한다.
-- Design Pattern은 변화 대비
프로그래머가 구현 할 시스템의 요구사항의 변화가 없고, 구현 후 변경사항이 없다면 굳이 Design Pattern을 적용할 필요는 없다. 그러나 실제 개발되는 대부분의 시스템들은 구현 후 긴 기간을 유지보수 기간을 가진다. 요구사항은 개발 후 변경은 말할 것도 없고, 개발기간에도 심없이 변경이 된다. 코딩 중에도 요구사항의 잘 못된 점을 변결하고 변경하야 하는 경우도 발생을 한다. 그래서 프로그래머들은 요구사항의 변화에 익숙해져야 하며, 변화에 대비하여 디자인해야 한다. 프로그래머의 경력은 이런것이 녹아있는 것이 아닌가 싶다. 경험 많은 프로그래머들은 항상 자신의 코드를 추상하하고, 일반적으로 만들려고 노력들을 한다. Design Pattern은 변화에 따른 변경되어야 하는 코드들을 최소화시켜준다. 지금까지 알려진 Design Pattern들을 하나 하나 유심히 보면 모든 Design Pattern의 초점은 "변화"라는 것을 파악할 수 있을 것이다.
-- Design Pattern을 적용할때 중요한 규칙
지금까지 소개 된 Design Pattern을 유심히 보면 공통 된 규칙이 존재한다는 것을 알수있다.
- 구현 클래스가 아닌 추상화 된 인터페이스로 프로그래밍하자.
[ Interface 바탕으로 하는 클래스 호출 ]
DataTranslator Object는 EnglishTranslatorImpl을 직접 바라보는 것이 아니라 항상 추상화 된 Translator(Interface)를 통해 보도록 한다. 실제 구현체인 EnglishTranslatorImpl이 변경되더라도 그를 사용하고 있는 Object(DataTranslator)는 영향을 받지 않도록 하기 위해서이다. Interface(Translator)는 가급적 변화되지 않게 일반적으로 추상화를 시켜야 한다.
모든 구현을 Interface를 통할 필요는 없다. 그러나, 복잡한 비즈니스 로직을 담고 있거나, 변경이 잦은 객체인 경우는 Interface를 가져가는 것이 시간이 흐를수록 좋다는 것을 느끼게 될 것이다.
- 상속(Inheritance)이 아니라 Delegation을 사용한다.
[ 상속 (Inheritance) ]
[ Delegation ]
- Coupling을 최소화함으로써 추후의 변화를 최소화한다.
어느 하나의 Object의 기능 변화가 전체 클래스 구조를 바꾸거나 혹은 많은 부분에 걸쳐 변화를 야기한다면 뭔가 객체설계가 잘 못 되어진 것이다. 그리고 여러 부분을 중복되서 수정하고 있다면 이 또한 뭔가 잘 못 되었다는 것이다. 모든 디자인 패턴들이 일관되게 말하는 것은 "Coupling을 최소화하라"이다.
