디자인패턴15 행동 패턴 - 방문자(Visitor) - 참조: https://refactoring.guru/design-patterns/visitor - 참조: GoF의 디자인 패턴 - 방문자(Visitor) 방문자패턴은 동작하는 객체로부터 알고리즘을 분리하는 패턴이다. - 문제점 하나의 거대한 그래프로 구성된 지리 정보로 동작하는 앱을 개발한다고 가정해보자. 그래프의 각 노드는 도시와 같은 복잡한 엔티티를 표현할 수 있지만 산업단지나 관광지 같은 더 세분화된 요소들도 표현할 수 있다. 이런 노드들은 그들이 표현하고 있는 객체들 사이에 길이 있다면 다른 요소와 연결되어 있을것이다. 이런 상황에서 각 노드의 타입은 클래스로 표현되지만 각 특정 노드는 객체이다. 시간이 지나서 그래프를 XML 형태로 변환하는 기능을 구현할 수도 있다. 언뜻 생각하기에는 별로 .. 2021. 6. 20. 행동 패턴 - 템플릿 메소스(Template Method) - 참조: https://refactoring.guru/design-patterns/template-method - 참조: GoF의 디자인 패턴 - 템플릿 메소드(Template Method) 템플릿 메소드 패턴은 부모 클래스에서 알고리즘의 뼈대를 정의하고, 서브 클래스에서 구조의 변화없이 알고리즘의 일부 단계를 재정의하는 패턴이다. - 문제점 기업의 문서를 분석하는 데이터 마이닝 어플리케이션을 만든다고 가정해보자. 사용자는 다양한 포맷(PDF, DOC, CSV)의 문서를 사용하고, 여러 포맷에서 의미있는 데이터를 단일 포맷으로 추출한다. 처음에는 DOC 파일에서만 동작하게 만들었다면 그 다음 버전에서는 CSV 를 또 몇개월 후에는 PDF 에서도 동작이 되도록 점점 기능을 확장할 가능성이 크다. 기능을 .. 2021. 6. 20. 행동 패턴 - 전략(Strategy) - 참조: https://refactoring.guru/design-patterns/strategy - 참조: GoF 의 디자인패턴 - 전략(Strategy) 패턴 정책(Policy) 라고도 하며 알고리즘 집단을 정의한다. 각각의 알고리즘을 분리된 클래스로 추출하고, 객체들간의 상호교환이 가능하도록 한다. - 문제점 여행자를 위한 네비게이션 앱을 만들기로 했다고 가정하자. 이 앱은 어느 도시에서는 사용자가 빠르게 방향을 잡을 수 있도록 지도를 중심으로 구성되어 있다. 이 앱에서 제일 중요한 기능은 자동으로 경로를 찾는것이다. 유저가 주소를 입력하면 목적지까지 가장 빠른 경로가 지도상에 표시된다. 앱의 초기버전은 자동차 도로를 통해서만 경로를 찾을 수 있게 만들었다. 차로 여행하는 사람들은 아무런 문제가 .. 2021. 6. 20. 행동 패턴 - 상태(State) - 참조: https://refactoring.guru/design-patterns/state - 참조: GoF의 디자인 패턴 - 상태(State) 패턴 상태 표현 객체(Object for state) 라고도 불리우며, 객체 내부의 상태가 변할 때 자신의 행동을 대체할 수 있도록 하는 패턴이다. 마치 객체가 자신의 클래스를 바꾸는것처럼 동작한다. - 문제점 상태 패턴은 대학교때 컴파일러 수업을 들었다면 자세한 내용이 기억나지는 않더라도 들어봤을법한 유한 상태 기계(Finite-State Machine)의 개념과 깊은 연관성이 있다. 메인 발상은 어떤 순간에 프로그램에서 존재하는 상태의 수가 유한하다는 것이다. 특정 상태 마다 프로그램은 모두 다르게 동작하며, 하나의 상태에서 다른 상태로 즉시 전환된다. .. 2021. 6. 19. 행동 패턴 - 옵저버(Observer) - 참조: https://refactoring.guru/design-patterns/observer - 참조: GoF의 디자인 패턴 - 옵저버(Observer) 패턴 옵저버 패턴은 종속자(Dependent), 게시-구독(Publisher-Subscribe) 패턴이라고도 불리우며, 디자인 패턴을 공부해보지 않았더라도 한번쯤은 들어봤을법한 유명한 패턴이다. 옵저버 패턴은 관찰하고 있는 객체에 일어난 사건을 여러 객체들에게 알리기위한 구독 매커니즘이다. - 문제점 Customer와 Store 객체의 타입이 있다고 가정해보자. 어떤 소비자는 매장에서 곧 출시될 특정 제품 브랜드에 관심이 많다. 이 소비자가 제품이 출시되었는지 확인하기 위해서 매일 매장을 방문할수도 있지만 이렇게 확인하는 방법은 너무 번거롭다. .. 2021. 6. 17. 행동 패턴 - 메멘토(Memento) - 참조: https://refactoring.guru/design-patterns/memento - 메멘토(Memento) 메멘토 패턴은 다른이름으로 "토큰" 이라고도 불리우며, 객체를 저장하거나 객체를 이전 상태로 되돌리기 위한 행동패턴이다. - 문제점 텍스트 에디터 앱을 만든다고 가정해보자. 간단한 텍스트 편집외에 포맷수정 및 이미지를 삽입하는 기능도 있다. 이 텍스트 에디터 앱을 사용하는 유저에게 실행취소 기능을 제공해준다고 할 때 가장 직관적인 구현방법은 다음과 같을 것이다. 모든 행위를 수행하기 전에 앱의 모든 객체의 상태를 기록하고, 장치에 저장한다. 이후에 유저가 해당 행위를 되돌리기 원할 때, 앱은 저장한 이력에서 마지막 스냅샷을 꺼내와서 모든 객체의 상태를 복구한다. 위의 방법에 대해서.. 2021. 6. 13. 행동 패턴 - 중재자(Mediator) - 참조: https://refactoring.guru/design-patterns/mediator - 중재자(Mediator) 패턴 중재자 패턴은 객체들간의 무질서한 의존성을 줄여주는 행동 패턴이다. 이 패턴은 객체들간의 직접적인 통신을 제한하고, 중재자 객체를 통해서만 협력하도록 강제한다. - 문제점 고객의 프로필을 만들고 수정하는 대화상자가 있다고 가정해보자. 이 대화상자에는 text 필드, 체크박스, 버튼 과 같은 다양한 요소가 있다. 웹서핑을 하다보면 form 요소들끼리 서로 연관있는 UI 를 본적이 있을것이다. 예를 들어 어떤 체크박스를 체크하면 인풋박스가 갑자기 나타나거나 저장버튼을 누르면 입력 필드에 대해서 Validation 메시지를 띄우기도 한다. 이런 로직의 코드가 form 요소안에 .. 2021. 6. 11. 행동 패턴 - 반복자(Iterator) https://refactoring.guru/design-patterns/command - 반복자(Iterator) 내부 표현계층을 외부로 노출하지 않고 collection의 원소들을 탐색할 수 있는 행동패턴이다. - 문제점 Collection 은 프로그래밍에서 가장 많이 사용되는 데이터형이긴 하지만 단지 객체들의 집합을 위한 컨테이너에 지나지 않는다. 대부분의 collection은 list로 원소들을 저장하고 있다. 그러나 일부는 스택이나 트리, 그래프 또는 다른 복잡한 데이터 구조에 기반하기도 한다. 하지만 아무리 collection이 구조적이라 하더라도, 다른 코드에서 collection을 사용하기 위해서는 원소들에 순차적으로 접근할 수 있어야 한다. List에 기반한 Collection이면 모든 .. 2021. 6. 8. 구조 패턴 - 프록시(Proxy) - 참조: GoF의 디자인패턴 - 참조: https://refactoring.guru/design-patterns/proxy - 프록시 패턴 다른이름으로 대리자(Surrogate) 라고도 하며 다른 객체에 대한 접근을 제어하기 위한 역할을 한다. - 문제점 많은 시스템의 리소스를 소비하는 객체가 있다고 가정하자. 해당 객체가 특정 시점이 되면 사용되겠지만 언제나 필요한건 아니다. 이때 흔히 알고 있는 Lazy loading 기법을 사용할 수 있다. 정말 필요한 시점에만 해당 객체를 생성하고, 해당 객체의 모든 클라이언트는 초기화 코드를 수행하면 된다. 하지만 이런 방식으로 구현하면 코드의 중복이 너무 많이 나타난다. 이런 코드를 해당 객체에 직접 넣는 방법도 있지만 만약 해당 클래스가 3rd-party .. 2021. 5. 20. 구조 패턴 - 플라이급(Flyweight) - 참조: https://refactoring.guru/design-patterns/flyweight - 플라이급(Flyweight) GoF의 디자인 패턴에서는 공유를 통해 많은 수의 소립 객체들을 효과적으로 지원한다고 되어있다. 대략적으로 의미는 알것 같기도 한데 뭔가 확실하게 와닿지는 않는다. 개인적으로는 refactoring.guru의 설명이 더 명료하고 와닿는다고 생각한다. refactoring.guru 에서는 "플라이급 패턴은 각 객체에서 데이터를 다루는 대신 객체들의 공통되는 상태를 공유하여 RAM을 확보하는 디자인 패턴이다." 라고 정의하고 있다. - 시나리오 플레이어가 맵을 돌아다니면서 서로 쏘는 게임을 만든다고 가정하자. 많은 양의 총알, 미사일, 파편들이 온 맵에 흩뿌려질것이다. 이 게.. 2021. 5. 19. 이전 1 2 다음
