기록하는 개발자

문제 상태(state)가 여러 개 있고, if 문으로 상태를 통제하여 코드가 반복되고 복잡하다. 해결 방안 상태를 한 곳에서 관리 목적 - 객체의 내부 상태가 바뀔 대 객체의 동작을 변경할 수 있도록 함. - 객체는 자신의 calss를 바꾸는 것처럼 보임. 결과 변경 최소화 State Patten 용어 State -시점에 따라 특정 상태가 있어야 함. -처음에 가지게 되는 초기 상태(state) 또는 상황에 따라 여러 상태 가운데 한 상태를 가질 수 있다. Transition(전이) -외부 입력에 따라 가능한 상태로 전환 ex) 가전 제품 : on, off, sleep... 게임 캐릭터 : 걷는 상태, 뛰는 상태, 멈춘 상태...

문제 서브 시스템이 너무 많고 사용하기가 복잡함 해결 방안 단순한 interface를 제공하는 객체를 중간에 넣음 목적 -서브 시스템에 있는 여러 개의 interface를 통합하는 한 개의 interface를 제공 - facade는 서브 시스템을 쉽게 사용할 수 있도록 해주는 고급 수준의 interface를 정의 결과 최소 지식 원칙에 입각해 의존성 최소화 Facade Pattern -어떤 서브시스템의 일련의 interface에 대한 통합된 interface를 제공 -facade에서 고수준 interface를 정의하므로 서브시스템을 더 쉽게 사용할 수 있다.

문제 사용 객체의 API가 서로 다름 해결 방안 함수를 변환하는 객체를 중간에 넣음 목적 -class의 interface를 client가 원하는 형태의 또 다른 인터페이스로 변환. -adapter는 호환되지 않는 interface 때문에 동작하지 않는 class 들을 함께 동작할 수 있도록 만들어 줌 결과 변경 최소화 Adapter Pattern 객체를 감싸는 역할을 한다.(Object wrapping) -서로 호환되지 않는 두 개 interface를 연결하는 작업 -서로 다른 interface를 동일하게 변환 객체 지향 Adapter -일상 생활에서 쓰이는 adapter와 똑같은 역할을 함. -어떠한 interface를 client에서 요구하는 형태의 interface에 적응시켜주는 역할을 함. Ada..

문제 사용 객체의 API가 서로 다름 해결 방안 실행과 요청을 분리 목적 - 요구사항(요청, 명령)을 객체로 캡슐화 시킴 - 이를 이용해 다른 요구사항을 지닌 클라이언트를 매개변수화 시킬 수 있음. - 요구사항을 큐에 넣거나 로그로 남길 수 있으며 작업 취소(undo) 기능 지원도 가능 결과 (작은)클래스가 많아지나, 객체 사용에 필요한 복잡성을 제거하고 감춘다(함수 이름이 동일해진다) 설계 *Decoupling : 요청과 실행을 분리 Command -Receiver를 알고 있고, Receiver의 method를 호출 - Receiver의 method에서 사용되는 매개변수의 값들은 Command에 저장됨 ex)Command, ConcreteCommand Receiver - 실제 명령(command)수행 ..

문제 여러 객체가 생성되면 상태 관리가 어려움 해결 방안 객체 생성자를 중앙 관리 목적 클래스가 1개의 instance만을 만들 수 있도록 하고, 어디서나 생성된 instance에 접근할 수 있도록 함 결과 객체가 1개라서 일관된 상태 고전적인 singleton pattern 구현 방법 private default 생성자 구현 singleton instance를 저장하는 정적 멤버 변수 생성 singleton instance를 반환하는 정적 factory method 구현 (multi-thread를 사용하는 프로그램에서는 문제가 될 수 있음) Thread-safe 버전의 singleton 여러 개의 스레드에서 위 코드가 사용되면 문제가 발생할 수 있다. 해결 방법 : getinstance() 함수에 동기..

Abstract Facotory Pattern(추상 팩토리 패턴) 목적 구체적인 클래스를 명시하지 않고 관련된 혹은 의존적인 객체들을 생성할 수 있는 인터페이스 제공 문제 -객체를 생성하는 'new'의 문제 → new는 interface가 아니라 실제 class의 객체를 생성 → OCP에 어긋나 생성할 객체가 늘어나면 코드 수정이 필요하다. 클래스가 많아지거나 변경되면 클라이언트 측 변경이 많아진다. Simple Factory simple factory가 어느 객체를 생성할 지 판단하고, 사용자 측에 맞는 객체를 반환 -일반적으로 if문에서 문자열에 따라 생성할 객체를 결정 -패턴이라고 볼 수는 없다. Facotory Pattern 문제 -실제로 구현되는 클래스의 객체를 생성할 때 객체의 종류가 달라지면..

문제 조금씩 다른 다양한 종류의 기능이 존재. 기능이 늘어날 수록 확장이 어렵다 해결 방안 상속을 사용하지 않고 연관으로 필요한 기능 추가. 실행 시점 확장 →상속은 compile time에 발생. 연관을 사용하므로써 실행 시점을 run time으로 확장 목적 - 객체에 추가적인 책임을 동적으로 부여한다. - decorator는 서브 클래싱(상속)을 사용하지 않아도 유연하고 융통성 있는 기능 확장을 가능하게 한다. 결과 확장성 조금씩 기능을 추가하기 위해 새로운 클래스를 생성하는 경우 -상속으로 문제를 해결할 시 너무 많은 상속 관계가 발생할 수 있다. -상속을 사용하지 않고 새로운 기능을 추가할 수 있는가? Component 각 구성요소는 직접 쓰일 수도 있고 decorator로 감싸져 쓰일 수도 있다..

문제 1:n 관계에서의 정보 갱신 해결 방안 사용자를 등록하고, 정보가 변경되는 경우를 알려주고 값을 자동으로 갱신 목적 - observer pattern은 일종의 push 서비스를 구현 - 객체간 1:다 의존 관계를 정의함. -1개 객체 상태가 변경될 때, 그 객체와 의존관계에 있는 모든 객체들이 자동으로 알림을 받고 상태를 갱신 한다. 결과 느슨한 커플링, 확장성 느슨한 커플링(Loose coupling) : 두 객체가 느슨하게 결합되어 있다는 것은, 그 둘이 상호작용을 하긴 하지만 서로에 대해 잘 모른다는 것을 의미한다. ·observer pattern 에서는 Subject와 Observer 간 느슨한 결합이 만들어진다. -Subject가 Observer에 대해서 아는 것은 특정 인터페이스를 구현한..