기록하는 개발자

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

문제 사용 객체의 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() 함수에 동기..

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

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

문제 알고리즘의 다른 버전이 존재하여, 중복으로 존재하거나 if문을 이용해 선택해야 한다. -> OCP 위반 해결 방안 중복을 공통화 시키고, 실행 시점에 맞는 알고리즘을 호출하도록 한다.(상속 도는 인터페이스 활용) 목적 -같은 종류의 작업을 하는 알고리즘을 정의, 캡슐화하여 알고리즘들을 서로 바꿔 사용 가능하도록 한다. -strategy pattern은 알고리즘을 사용하는 클라이언트로부터 독립적으로 알고리즘을 바꿔서 적용시킬 수 있도록 한다. *policy pattern 이라고 부르기도 함 : 여러 정책(policy)가 존재하고, 상황에 따라 적합한 정책을 적용 시킨다. ex) 액자를 거는 방법 : 양면 tape로 고정한다, 못을 박는다, 고정핀을 이용한다 --> 여러 알고리즘 존재 결과 수정할 경우..