기록하는 개발자

문제 여러 객체가 생성되면 상태 관리가 어려움 해결 방안 객체 생성자를 중앙 관리 목적 클래스가 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에 대해서 아는 것은 특정 인터페이스를 구현한..

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