본문 바로가기

취업과 기본기 튼튼/빽 투더 기본기

 (38)
[디자인 패턴 18편] 디자인 패턴 총 정리. 구조편 들어가기 앞서 들어가기 앞서, 먼저 디자인 패턴에 대해 어떻게 생각하고 받아들여야 할지 고민해본다. 디자인 패턴이라고 하는 개념들은 왜 있으며, 왜 배우고 정리하는걸까? 디자인 패턴에 대한 검색을 해보면, 각 패턴에 대한 무수한 예제들이 있다. 예제도 다양한데 각 구현부가 달라 무엇을 기억해야 하는지 헷갈릴 때가 종종 있곤 했다. 또, 이 패턴과 저 패턴이 비슷해 보일 때도 있으며, 실제로 두 패턴을 무엇으로 구분하나 싶기도 하다. 이러던 중, 이승현 님 블로그에 다음과 같은 글을 보았다. 패턴을 공부하거나 구현할 때 UML에 집중해서 공부하면 안 된다고 생각한다. 구조만을 외우고 구조로 구분을 한 사람은 공부한 것을 금방 까먹거나 헷갈려하기 쉽기 때문인데, 이유는 거의 비슷한 구조를 갖춘 패턴들은 정말..
[디자인 패턴 17편] 디자인 패턴 총 정리. 생성편 지금까지 공부하며 정리한 GoF 디자인 패턴을 총 정리해보려고 한다. 최대한 간결하고 필요한 것만 남겨본다. 여기서는 구체적인 구현 코드는 적지않고, 이미 패턴이 구현된 객체들을 사용하는 코드만 적겠다. 사용자 코드만 봐도 어떻게 작동하는지 알 수 있을거라 생각한다. (또 이렇게 사용자 코드만 봐도 이해가 가도록 구현해놓는 코드가 좋은 코드, 패턴이라고 생각한다.) 구현 코드는 대충 참고만할 수 있게, 클래스 다이어그램만 남겨둔다. 먼저 객체의 생성에 대해 다루는 생성편이다. 싱글톤 (Signleton) 코드 내 어디서든, 오직 하나의 인스턴스만 사용할 수 있도록 객체를 생성하는 방법이다. 즉 객체는 여러 번 생성되지 않고, 최초 하나의(Single) 인스턴스만 생성하고, 이후에는 이 인스턴스를 참조하게..
[디자인 패턴 16편] 행동 패턴, 커맨드 (Command) 1. 개념 커맨드 패턴은 특정 객체에 대한 커맨드를 객체화하여 이 커맨드 객체를 필요에 따라 처리하는 패턴이다. 가장 주의 깊게 볼 사항은 커맨드 자체를 객체화한다는 점이다. 보통 OOP 에서는 주체 객체와 대상 객체가 존재하고, 대상 객체에 대한 액션은 주체 객체에서의 메쏘드로 처리하는데, 이 액션까지 객체로 만든 뒤에 처리하겠다는 말이다. 처음엔 이렇게만 봐서 이해가 절대 안 간다. 자세한 내용은 차차 설명하겠다. 1.1. 첫 번째 예시 아무래도 커맨드 패턴은 조금 복잡해서 처음에 적절한 예시가 필요한 거 같다. 가장 많이 사용되는 '손님 - 웨이터 - 주방장' 예시를 들어보려고 한다. 다음과 같이 가게에 손님이 음식을 요청하는 상황을 생각해보자. 어떤 식당에는 주방장과 웨이터가 있다. 이 식당에 어..
[디자인 패턴 15편] 행동 패턴, 방문자 (Visitor) 1. 개념 비지터 패턴은 방문자와 방문 공간을 분리하여, 방문 공간이 방문자를 맞이할 때, 이후에 대한 행동을 방문자에게 위임하는 패턴이다. 간단하게 설명하기 참 어려운 패턴이다. 보통 OOP에서, 객체는 그 객체가 하는 행동을 메쏘드로 가지고 있다. 그리고 행동의 대상이 되는 객체가 있을 경우, 메쏘드의 파라미터로 입력받는다. 그런데, 비지터 패턴은 행동의 대상이 되는 객체가 행동을 일으키는 객체를 입력으로 받는다. 설명이 좀 어려운데, 간단히 예로 설명하면 다음과 같다. "나는 상점에 방문한다. 나는 ~를 한다." '나'라는 객체가 '상점'이라는 객체를 입력받은 후, 이 상점에 대해서 뭔가를 한다. 이게 일반적인 OOP 추상화다. 반면 비지터 패턴은 다음과 같다. "상점에 내가 방문을 했다. 내가 ~..
[디자인 패턴 14편] 행동 패턴, 책임 연쇄 (Chain of responsibility) 1. 개념 책임 연쇄 패턴은 요청을 처리하는 동일 인터페이스 객체들을 체인 형태로 연결해놓는 패턴이다. 앞의 객체의 요청을 처리하지 못할 경우, 같은 인터페이스의 다른 객체에게 해당 요청을 전달한다. 1.1. 구조 Handler 요청을 처리하는 목적의 추상 클래스 ConcreteHandler 가 이를 상속받아 HandleRequest() 를 구현한다. ConcreteHandler Handler 를 상속받아 요청 처리를 구현하는 구체적인 클래스 1.2. 장단점 이것도 역시 상황에 맞게 사용되는거라 딱히 장단점을 말할 수 는 없을 듯? 1.3. 활용 상황 말 그대로 객체가 동일한 인터페이스(기능)을 갖되 요청을 처리는데, 이 요청을 처리하지 못할 시, 이걸 처리해줄 그 다음 객체를 지정해야 할 때. 요청을 ..
[디자인 패턴 13편] 행동 패턴, 상태 (State) 1. 개념 상태 패턴은 상태 자체를 객체화함으로써, 상태에 따른 액션도 상태 객체에 내부에 구현하는 패턴이다. 덧붙이면, 보통 객체를 추상화할 때 행동의 주체가 클래스, 대상이 하는 행동이 메쏘드로 정의되고,해당 대상의 상태는 속성으로 정의된다. 따라서 현재 주체의 상태에 따라 행동이 다를 경우, 상태에 조건문을 두어 행동을 다르게 하는 경우가 많다. 그런데 이러면 상태의 종류가 많아질수록 조건문도 많아지게 되고, 코드의 가독성이 떨어지게 된다는 단점이 있다. 이를 보완하고자, 상태 자체를 객체로 만들고 상태에 따른 액션도 이 객체에다가 포함시킨다. 이러면, 주체는 상태를 일일이 조건문으로 검사하지 않고, 올바른 상태 객체의 액션만 실행시키면 원래 원하던 일을 수행할 수 있다. 1.1. 구조 State ..
[디자인 패턴 12편] 행동 패턴, 옵저버(Observer) 1. 개념 옵저터 패턴은 하나의 관찰대상 - 여러 개의 관찰자 구조가 필요할 때 쓰는 패턴이다. 1.1. 구조 Subject 관찰 대상이 되는 객체 자신을 관찰하는 옵저버들 리스트를 가지고 관리도 함. 옵저버 붙이기(attach), 떼기(detach), 알리기(notfiy) 를 가지고 있어야 함. Observer Subject 를 관찰하는 객체 Subejct 가 notify 를 호출하면 Observer 의 update 도 호출됨. 즉 Observer.update() 에 관찰 대상이 notify 했을 때의 할 일들을 적으면 됨. 1.2. 장단점 딱히 장단점 가릴게 없는 패턴인거 같다. 필요에 따라 쓰는 패턴. 1.3. 활용 상황 관찰대상 - 관찰자의 구조를 가질 때 쓰면 된다. 이벤트 핸들러가 대표적인 옵..
[디자인 패턴 11편] 행동 패턴, 템플릿메쏘드(Template method) 1. 개념 템플릿메쏘드 패턴은 상위 클래스가 뼈대가 되는 로직을 구성하고, 하위 클래스들이 이 로직의 요소들을 각각 구현하는 패턴이다. 1.1. 구조 AbstractClass ConcreteClass 가 상속받아야 할 추상 클래스 templateMethod() 에 클라이언트가 사용할 로직을 담는다. 각 로직의 요소는 method1(), method2() 에 담기며, 이는 ConcreteClass 에서 구현한다. ConcreteClass AbstractClass 를 상속받아, 필요한 로직 요소 method() 를 필요에 맞게 구현한다. 1.2. 장점 로직과 로직요소를 분리하여, 전체 로직은 동일하되 로직 요소를 각각 다르게할 수 있다. 1.3. 단점 추상 클래스와 구현 클래스가 강하게 연결되어 있다. 상속..

티스토리툴바