디자인 패턴 #1 - 스트래티지 패턴 (strategy pattern)

1. 스트래티지 패턴 (strategy pattern)
스트래티지 패턴(strategy pattern)에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다. 스트래티지를 활용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.

쉽게 이야기하자면 지정된 알고리즘의 세부 구현을 변경할 필요없이 쉽게 교환할 수 있게 해주는 디자인 패턴이다.

클래스 다이어그램을 살펴보면 오리의 행동을 정의한 2가지 interface가 존재하고,
Duck 클래스를 상속받은 오리(MallardDuck, RedheadDuck, RubberDuck)은 각자에게 맞는 행동 객체를 할당하여 사용할 수 있다. 만일 행위가 변경된다면 원하는 행동 객체를 할당하여 쉽게 교체하여 사용할 수 있다. 하기의 RubberDuck을 구현한 코드를 살펴보면 RubberDuck에 맞게 FlyBehavior와 QuackBehavior에 객체를 할당하여 사용하면 되며, 행위에 변경이 발생하더라도 해당 행위에 맞는 객체로 교체해주면 쉽게 동작을 변경할 수 있다.


위의 방식처럼 클래스를 합치는 것을 구성(composition) 관계라 한다. 구성(composition)이란 클래스를 상속하는 대신 기존 클래스(super class)의 인스턴스를 참조하는 private 필드를 서브 클래스로 만들고자 했던 클래스에 만드는 것이다. 즉 RubberDuck 클래스는 Duck 클래스를 상속하는 대신에 Duck 클래스에 추가된 FlyBehavior와 QuackBehavior를 RubberDuck 클래스에서 행동에 맞는 객체를 할당하여 사용하였다.

이와같이 구조를 잡을 때에는 각 클래스의 관계가 'is-a'인지, 'has-a'인지를 이해하고, 관계에 맞는 구조를 잡아주는 것이 좋다. 만일 두 클래스 간의 관계에 대해 자신있게 'is-a'가 맞다고 이야기할 수 없다면 상속(inheritance)은 피해야 하며, 구성(composition) 사용을 고려해봐야한다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

아스키 코드(ASCII)와 유니코드(unicode)

이미지
1. 아스키 코드(ASCII) American Standard Code for Information Interchange의 약자로, 1960년대 미국 ANSI에서 표준화한 정보교환용 7비트 부호체계이다. 8비트 중에서 7비트만 사용하여 총 128개의 부호를 표기할 수 있다. 나머지 1비트는 통신 에러 검출을 위한 것으로 1의 개수가 홀수이면 1, 짝수이면 0으로 표기하였다. 이를 parity bit라고 한다. 이후 1비트를 더 확장한 ANSI 코드가 나왔으나 이것만으로는 다른 언어를 표현할 수 없었다. 이를 해결하기 위해 국제 표준 코드인 유니코드(Unicode)가 등장하게 되었다. [아스키 코드표] 2. 유니코드(Unicode) 초기 유니코드는 다양한 언어를 지원하기 위해 2바이트(=65536)로 용량을 확장하였다. 그러나 2바이트만으로는 고어(古語), 토속어 등을 담기에는 역부족이었다. 이러한 문제점을 해결하기위해 기본언어판과 보충언어판(BMP + SMP)으로 구성된 유니코드 3.0을 출시하게된다. (2019년 5월 7일 현재, 유니코드 버전 12.1) 유니코드 인코딩은 UTF-8, UTF-16, UTF-32 등이 있으며, 유니코드라 하면 일반적으로 UTF-8이 사용된다. UTF-8로 표현 가능한 길이는 최대 6바이트이나 다른 인코딩과의 호환을 위해 4바이트까지만 사용된다. 1바이트 영역은 아스키 코드와 하위 호환성을 가지며, 아스키 코드의 0~127까지는 UTF-8로 완전히 동일하게 사용된다. 아스키 코드와의 호환은 인터넷에서 가장 많이 사용되는 인코딩이 되는데 큰 이점으로 작용하였다. 유니코드가 쓰이기 전에는 대부분의 인터넷 문서들이 아스키 코드로 작성되었기 때문에 기존 인터넷 문서를 문제없이 호환된다는 것은 큰 장점이었다. UTF-8의 인코딩 규칙은 바이트가 추가될 때마다 1번째 바이트에 '1'로 표기해주는 방식이다. 1개의 바이트가 추가되었다면 '110'을, 2개의 바이트가 추가되었다면 
자세한 내용 보기

네트워크의 기본 #2 - TCP/IP 4계층

이미지
1. TCP와 IP TCP/IP는 Internet에서 사용되는 protocol이다. 1960년대 미국방성의 연구에서 시작되어 1980년대에 protocol model이 공개되었다. hardware, OS, 매체에 관계없이 동작할 수 있다. 패킷  통신 방식의 인터넷 프로토콜인 IP(Internet Protocol)와 전송 조절 프로토콜인 TCP(Transmission Control Protocol)로 이루어져있다. IP는 패킷 전달 여부를 보증하지 않고, 패킷을 보낸 순서와 받는 순서가 다를 수 있다. TCP는 IP 위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다. HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 application protocol들이 IP 위에서 동작하기 때문에 TCP/IP로 부르기도 한다. TCP/IP protocol은 OSI 모형보다 먼저 개발되었다. TCP/IP 프로토콜은 OSI 모형과 정확하게 일치하지는 않지만, OSI 모형을 4계층 혹은 5계층으로 분류하여 적용할 수 있다. 2. 각 Layer별 기능 Layer 1 : 네트워크 연결 계층 (Network Access Layer) - Ethernet, Wi-Fi, Token ring TCP/IP 패킷을 네트워크 매체로 전달하는 것과 네트워크 매체에서 TCP/IP 패킷을 받아들이는 과정을 담당한다. 기본적으로 에러검출 / 패킷의 프레임화를 담당한다. Layer 2 : 인터넷 계층 (Internet Layer) - IP (IPv4, IPv6) 논리적인 주소 IP를 이용한 노드간 전송과 라우팅 기능을 처리하게 된다. 네트워크상 최종 목적지까지 정확하게 연결되도록 연결성을 제공한다. Layer 3 : 전송 계층 (Transport Layer) - TCP, UDP, DCCP, SCTP, IL, RUDP 자료의 송수신을 담당한다. 애플리케이션 계층의 세션과 데이터그램 통신서비스 제공한다. Layer 4 : 응용
자세한 내용 보기

디자인 패턴 #5 - 컴포지트 패턴 (composite pattern)

이미지
1. 컴포지트 패턴 (composite pattern) 객체들의 관계를 트리 구조로 구성하여 부분-전체를 나타내는 계층 구조로 만들 수 있다. 이 패턴을 이용하면 클라이언트에서 단일 객체와 여러 객체들로 구성된 복합 객체 모두 동일하게 다루도록 한다. 쉽게 표현하자면 담는 그릇과 내용물을 동일하게 다루는 것으로 디렉토리 트리 구조가 이에 해당한다. 파일 관리자와 같은 디렉토리 트리 구조는 디렉토리와 파일을 동일한 개념으로 다룬다. 사용자가 디렉토리의 depth를 변경하며 이동할 수 있고, 특정 디렉토리에 속한 디렉토리와 파일 목록을 보여준다. 디렉토리와 파일을 담고 있는 디렉토리도 같은 레벨의 파일과 동일하게 취급하게 된다.(이해가 어려우면 당장 핸드폰의 파일관리자를 실행해보라.) 파일관리자와 클래스 다이어그램을 비교하자면 Composite 클래스는 디렉토리를, Leaf를 파일을 의미한다. Composite 클래스와 Leaf 클래스는 Component 추상 클래스를 상속받았기 때문에 동일하게 취급할 수 있다. 이러한 composite 패턴의 특징을 이용해 디렉토리 트리 구조를 만들고, 다룰 수 있다. Component는 추상 클래스로 Directory의 reference를 가지고 있다. add(), getChildren()은 필요 시 하위 클래스에서 override하여 구현한다. mParentDirectory는 부모 디렉토리 참조이며, getAbsolutePath() 호출 시 재귀호출을 통해 절대 경로를 완성한다. 클래스 다이어그램에 나타난 것과 같이 Directory 클래스는 하위 클래스를 가질 수 있고, 이를 지원하기 위한 메소드를 override하여 정의한다. File 클래스는 Leaf에 해당하는 클래스로 트리 구조의 마지막에 위치한다.
자세한 내용 보기