#design pattern

컴포짓 패턴은 part-whole의 관계를 갖는 객체들을 정의할때 유용하다. 여러 객체가 한 클래스 전체 객체의 일부분으로 정의될때 사용한다. 부분 객체의 추가나 삭제가 있어도 전체 클래스의 코드를 변경하지 않으면 컴포짓 패턴은 유용하다. 그리고 클라이언트는 whole과 part를 구분하지 않고 동일한 인터페이스를 가질 수 있다. 컴퓨터를 모델링해보자. 컴퓨터에는 Keyboard, Monitor, RAM, SSD, CPU등이 있다. 각각의 클래스를 정의하고 Computer 클래스는 이들 구성 장치를 포함하는것으로 구성할 수 있다.

추상 팩토리 패턴은 관련성 있는 여러 종류의 객체를 일관된 방식으로 생성하는 경우에 유용하다. 계속되는 엘리베이터 예제에서 벤더에 따른 코드를 작성하면 벤더가 바뀌었을때 모든 부품의 코드가 벤더를 이동해야한다. 이런 경우에 부품별로 Factory를 정의하는 대신 관련 객체들을 일관성 있게 생성 할 수 있도록 Factory클래스를 정의하는 것이 효과적이다. 예를들어 Motor클래스를 위한 MotorFactory나 Door클래스를 위한 DoorFactory 대신 벤더에 따른 Factory를 정의하는것이 바람직하다. 엘리베이터를 구성하는

팩토리 메소드 패턴은 객체의 새성 코드를 별도의 클래스 또는 메소드로 분리함으로써 객체 생성의 변화에 대비하는데 유용하다. 프로그램이 제공하는 기능은 상황에 따라 변경될 수 있다. 그리고 특정 기능의 구현은 개별 클래스를 통해 제공되는 것이 바람직한 설계다. 그러므로 기능의 변경이나 상황에 따른 기능의 선택은 바로 해당 객체를 생성하는 코드의 변경을 초래한다. 게다가 상황에 따라 적절한 코드를 생성하는 코드는 자주 중복 될 수 있다. 이런 경우 객체 생성 방식의 변화는 해당되는 모든 코드 부분을 변경해야 하는 문제를 야기한다. 여기

템플릿 메소드 패턴은 전체적으로 동일하면서 부분적으로는 다른 구문으로 구성된 메소드의 코드 중복을 최소화 할 때 유용하다. 다른관점에서 보면 동일한 기능을 상위 클래스에서 정의하면서 확장과 변화가 필요한 부분만 서브 클래스에서 구현할 수 있도록 한다 엘리베이터 제어 시스템에서 모터를 구동시키는 기능을 생각해보자. 예를 들어 A모터를 이용하는 제어잇스템이라면 AMotor 클래스에 move()메소드를 정의할 수 있다. 또한 엘리베이터가 이미 이동중이라면 모터를 구동 시킬 필요가 없다. MortorStatus, DoorStatus, Di

Oberver패턴은 데이터의 변경이 발생했을 경우 상대 클래스나 객체에 의존하지 않으면서 데이터 변경을 통보하고자 할 때 유용하다. 예를 들어 새로운 파일이 추가되거나 기존 파일이 삭제되었을 때 탐색기는 이를 즉시 표시할 필요가 있다. 다른 예로는 차량의 연료가 소진될 떄 까지 주행 가능 거리를 출력하는 클래스, 연료량이 부족하면 메시지를 보내는 클래스 등이 있다. 입력된 성적 값을 출력하는 프로그램을 만들어 보자. 입력된 점수를 저장하는 ScoreRecord클래스와 점수를 목록 형태로 출력하는 DataSheetView클래스가 필요

Command패턴은 이벤트가 발생했을 때 실행될 기능이 다양하면서도 변경이 필요한 경우에 이벤트를 발생시키는 클래스를 변경하지 않고도 재사용을 가능하게 할때 유용하다. 실행될 기능을 캡슐화함으로써 기능의 실행을 요구하는 Invoker 클래스와 실제 기능을 실행하는 Receiver클래스 사이의 의존성을 제거한다. 따라서 실행될 기능의 변경에도 Invoker 클래스를 수정없이 그대로 사용할 수 있도록 해준다. 램프를 켜는 버튼을 만들어보자 Button클래스의 생성자를 이용해 불을 켤 Lamp객체를 전달한다. Button클래스의 pres

실세계의 많은개체는 자신이 처한 상태에 따라 일을 다르게 수행한다. 비가 오거나 눈이 오거나 사람이 많이 붐비는 장소에 있거나 따라 걷는 방식과 말하는 방식이 달리지는 것과 마찬가지인 이치다. 이를 표현하는 가장 직접적이고 직관적인 방법은 이를 수행할 때의 상태에 따라 상태 하나하나를 검사해 일을 다르게 수행하게끔 하는 것이다. 이는 분명히 복잡한 조건식이 있는 코드를 산출할 것이고, 결과적으로 코드를 이해하거나 수정하기 어렵게 만든다. 이런 방식과 달리 State패턴은 어떤 행위를 수행할 때 상태에 행위를 수행하도록 위임한다. 이

싱글톤 패턴은 인스턴스를 하나만 만들어 사용하기 위한 패턴이다. Connection pool, thread pool, device configuration 객체 등과 같은 경우 인스턴스를 여러개 만들게 되면 불필요한 자원을 사용하게 되고, connection pool의 예를 들면 계속 커넥션을 맺고 끊는 작업이 반복되거나 요청이 많아지면 DBMS에 부담이 많이 가게 되는 문제가 발생한다. (마치 php같아진다) 싱글톤 패턴으로 객체를 생성하면 두개의 인스턴스가 존재할 수 없게 된다. 이를 구현하려면 생성자에 제약을 걸어야 하고 단일