[Dev] 디자인 패턴
in Dev
생성 패턴
싱글톤 패턴
- 클래스의 인스턴스가 하나임을 보장하고 전역적인 접근점을 제공
- 똑같은 인스턴스를 여러 개 만드는 것이 아니라 기존에 생성했던 동일한 인스턴스를 제공
- 사용 예: 로그, 설정
- 문제점: 멀티스레드 환경에서 동기화 문제, 싱글톤 객체 역할이 복잡한 경우 다른 객체와 결합도가 높아져 OCP 위반 가능성이 높아짐
팩토리 메서드 패턴
- 조건에 따라 객체를 다르게 생성해야 되는 경우
- 분기에 따른 객체 생성을 직접하지 않고 팩토리라는 클래스에 위임하여 팩토리 클래스가 객체를 생성하도록 함
추상 팩토리 패턴
- 서로 관련이 있는 객체들을 통째로 묶어서 팩토리 클래스로 만들고 이들 팩토리를 조건에 따라 생성하도록 다시 팩토리를 만들어서 객체를 생성
- 관련된 객체들을 캡슐화하여 일관된 객체 생성이 가능
구조 패턴
어댑터 패턴
- 한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환
- 어댑터를 통해 인터페이스 호환성 문제 등으로 같이 사용할 수 없는 클래스들을 연결해서 사용할 수 있음
데코레이터 패턴
- 어떤 기능에 추가적으로 기능을 덧붙이고 싶은 경우, 그 기능들을 데코레이터로 만들어서 덧붙이는 방식
퍼사드 패턴
- 어떤 서브시스템의 일련의 인터페이스에 대해 통합된 인터페이스를 제공
- 고수준의 인터페이스를 통해 서브시스템을 쉽게 사용할 수 있음
- dvd 플레이어, cd 플레이어, 프로젝트, 스크린 등을 홈시어터라는 하나의 인터페이스로 통합하여 제공
프록시 패턴
- 어떤 객체에 대한 접근을 제어하는 용도로 대리인에 해당하는 객체를 제공하는 패턴
- 해당 객체가 원격 시스템에서 돌아가거나, 객체 생성 비용이 크거나, 접근 제한 제어를 해야 하는 경우에 사용
- 클라이언트->프록시->실제객체
행위 패턴
옵저버 패턴
- 어떤 객체에 이벤트가 발생했을 때, 관련된 객체들(옵저버들)에 통지하도록 하는 패턴
- 객체 상태가 변경되었을 때 특정 객체에 의존하지 않으면서 상태의 변경을 관련 객체들에 통지하는 것이 가능
- Pub/Sub 모델로 불리기도 함
커맨드 패턴
- 객체의 행위(메서드)를 클래스로 만들어 캡슐화하는 패턴
- 타 객체의 메서드를 실행하려면 참조를 해야하는 의존성이 생기는데, 커맨드 패턴을 통해 의존성 제거가 가능
- 참고
상태 패턴
- 상태에 따라 행위를 달리해야 하는 경우에 사용
- 자신이 직접 상태를 체크하지 않고 상태를 객체화하여 상태가 행동을 할 수 있도록 위임
- 참고
전략 패턴
- 객체들이 할 수 있는 행위 각각에 대해 전략 클래스를 생성하고, 유사한 행위를 하는 인터페이스를 정의
- 객체의 행위를 동적으로 바꾸고 싶은 경우, 직접 행위를 수정하지 않고 전략을 바꿔줌으로써 OCP 를 만족
- 참고
템플릿 패턴
- 특정 작업을 처리하는 일 부분을 서브 클래스로 캡슐화
- 동일한 기능은 상위 클래스에 정의하고 확장/변화가 필요한 부분만 서브 클래스에서 구현
