나머지 패턴

디자인 패턴의 정의?

• 패턴이란 특정 컨텍스트 내에서 주어진 문제에 대한 해결책이다!.

• 컨텍스트(context)란? 패턴이 적용되는 상황을 뜻합니다. 반복적으로 일어날 수 있는 상황이어야만 합니다. 예 : 객체들의 컬렉션이 주어져 있습니다. (열쇠를 차에 두고 문을 잠그고 나와 버렸다.)
• 문제(problem)란? 그 컨텍스트 내에서 이루고자 하는 목적을 뜻합니다. 하지만 컨텍스트 내에서 생길 수 있는 제약조건도 문제에 포함됩니다. 예 : 컬렉션의 구현을 드러내지 않으면서 그 안에 있는 각 객체들에 대해서 순환작업을 할 수 있어야 합니다. (어떻게 회사에 제 시간에 도착할 것인가?)
• 해결책(solution)? 누구든지 적용해서 일련의 제약조건 내에서 목적을 달성할 수 있는 일반적인 디자인을 뜻합니다. 예 : 반복 작업을 별도의 클래스로 캡슐화 시킵니다. (유리를 깬다. 차에 들어간다. 시동을 걸고 차를 몰고 출근한다.)
• ()안에 있는 예는 디자인 패턴의 정의에 의하면 올바른 패턴이라고 할 수 있을까?

• 없다. 이유는 1. 해결책으로 차유리를 깨는 방법은 반복적으로 적용할 수 있는 해결책이라고 할수 없으며 2. 이런 해결책을 다른 사람한테 알려주고 그 사람이 처한 문제에 대한 해결책으로 적용하기 힘든점 3. 패턴에 이름이 붙이지 않았기에 다른 개발자들하고 그 패턴에 대해서 토론하는 것이 불가능하다.

• 디자인 패턴의 정의? “ 어떤 컨텍스트 내에서 일련의 제약조건에 의해 영향을 받을 수 있는 문제에 봉착했다면, 그 제약조건 내에서 목적을 달성하기 위한 해결책을 찾아낼 수 있는 디자인을 적용하면 된다. 단순히 표현하면 반복적으로 등장하는 디자인 문제에 대한 해결책 “
• 디자인 패턴을 정형적으로 기술해 놓아야 카탈로그?를 만들수 있다.

• 패턴 카탈로그란? 가장 훌륭한 패턴 카탈로그는 Design Patterns: Elements of Reusable Object-Oriented Software -> GoF의 디자인패턴(한글번역 판) 이 카탈로그에는 23개의 기본 패턴이 수록

• 패턴 카탈로그의 기술 형식!
• 패턴 이름 패턴 설명에서 가장 먼저 등장, 패턴의 이름 없이는 패턴에 대한 정보를 다른 개발자들과 공유하기가 아주 힘들어 진다.
• 용도(Intent) 패턴의 역할이 간단히 기술된다.
• 동기(Motivation) 문제를 기술하고 주어진 해결책이 어떤 식으로 그 문제를 해결 할 수 있는지를 보여줄 수 있는 구체적인 시나리오가 주어진다.
• 적용대상(Applicability) 패턴을 적용할 수 있는 상황이 기술된다.
• 구조(Structure) 패턴에서 사용되는 클래스 다이어그램이 수록된다.
• 구성요소(Participant) 디자인패턴에 포함되어 있는 클래스와 객체들에 대한 설명
• 협동(Collaboration) 각 구성요소들이 패턴 내에서 어떤 식으로 도움을 주는지 설명.
• 결과(Consequence) 패턴을 사용했을 때의 효과(장점 및 단점)가 수록됨
• 구현(Implementation) 패턴을 구현할 때 필요한 기술 및 주의사항에 대해 설명
• 샘플코드(Sample Code) 구현시 도움 될 만한 코드 제공
• 사용예(Known Uses) 실제 시스템에서 이 패턴을 사용하는 예에 대한 설명
• 관련패턴 (Related Patterns) 본 패턴과 유사하거나 밀접하게 관련된 다른 패턴에 대해서 기술

디자인패턴은 만병 통치약이 아니다!

• 패턴은 반복적으로 발생하는 문제에 대한 일반적인 해결책이다.
• 다만 패턴이 필요하다고 결론을 내리고 나면 다른 개발자들도 비슷한 문제를 겪었고, 비슷한 기법을 적용해서 그 문제를 해결 했다고 생각 할 수 있다.
• 패턴을 사용한다고 기적 같이 문제가 해결되진 않는다. 그 패턴을 사용했을 때 여러분이 설계한 디자인의 다른 부분에 미칠 수 있는 영향과 결과에 대해 주의깊게 생각해 보아야 한다.

디자인 패턴이 필요한 경우?

• 디자인상의 문제에 적합하다는 확신이 들 경우에 패턴을 도입해야한다.
• 언제 패턴을 적용할지를 올바르게 결정하려면 상당한 경험과 지식이 축척되어야 합니다.
• 만약 더 간단한 해결책이 있다면 패턴을 적용하기 전에 그 해결책을 사용하는 것을 고려해야 한다.
• 패턴을 도입하는 것은 디자인 단계에서만 고려해야 하는 일이 아니라, 리팩토링 할 때도 패턴을 고려해보는 것이 좋다.

리팩터링과 패턴

• 리팩터링이란 코드 구조를 개선하기 위해서 코드를 변경하는 과정을 뜻한다.
• 예를들면 조건문이 아주 많이 있는 코드가 있으면 스테이트 패턴을 적용하는 것을 고려해볼만 하다.

패턴을 대하는 마음가짐

• 초급자 언제나 패턴을 사용하는 경향이 있습니다. Hello World 프로그램에도 패턴을 써봐야지 이러한 과정에서 패턴을 쓰는 연습을 하면서 다양한 경험을 쌓을 수 있다.
• 중급자 경험이 늘어감에 따라 중급자 수준에 오르게 되면 어떤 상황에서 패턴이 필요하고 어떤 상황에서 패턴이 필요하지 않은지를 파악할 수 있다.
• 달인 달인의 경지에 오르게 되면 패턴을 자연스럽게 구사할 수 있습니다. 더 이상 패턴을 사용하는 것에 얽매이지 않고, 문제를 가장 효과적으로 해결할 수 있는 해결책을 찾는데 주안점을 둘뿐!

사악한 안티 패턴? 섬멸하기~!

• 안티 패턴은 어떤 문제에 대한 나쁜 해결책에 이르는 길을 알려줍니다.
• 안티 패턴에서는 어떤 이유로 나쁜 해결책에 유혹될 수 있는지를 알려줍니다.
• 안티 패턴은 장기적인 관점에서 그 해결책이 나븐 이유를 알려줍니다.
• 안티 패턴에서는 좋은 해결책을 만들어 내기 위해 적용할 수 있는 다른 패턴을 제안해 줍니다.
• page 645에 안티패턴의 예시가 있습니다.

브리지 패턴

1. 브리지 패턴
   • 구현 뿐만 아니라 추상화된 부분까지 변경시켜야 하는 경우에는 브리지 패턴을 사용
   • 인터페이스와 실행을 분리하여 독립적으로 변할 수 있게 함
2. 왜 브리지 패턴을 사용하는가?
   • 추상화된 부분과 추상 클래스/인터페이스를 구현한 클래스를 서로 다른 클래스 계층구조에 집어 넣음으로써 그 둘을 모두 변경시킬 수 있습니다.
3. 브리지의 장점
   • 구현을 인터페이스에 완전히 결합시키지 않았기 때문에 구현과 추상화된 부분을 분리시킬 수 있습니다. (기능부와 구현부를 분리)
   • 추상화된 부분과 실제 구현 부분을 독립적으로 확장할 수 있습니다. (기능을 추가로 넣거나 구현을 바꿀때 독립적으로 할 수 있다.)
   • 추상화된 부분을 구현한 구상클래스를 바꿔도 클라이언트 쪽에는 영향을 끼치지 않습니다.
4. 브리지 활용법 및 단점
   • 여러 플랫폼에서 사용해야 할 그래픽스 및 윈도우 처리 시스템에서 유용하게 쓰입니다.
   • 인터페이스와 실제 구현부를 서로 다른 방식으로 변경해야 하는 경우에 유용하게 쓰입니다
   • 디자인이 복잡해진다는 단점이있습니다.

빌더 패턴

• Builder Pattern은 생성자 패턴 중 하나이다.