6. 옵저버 패턴에서 일어나는 일
1. 독자가 주제 객체한테 옵저버가 되고 싶다고 이야기를 한다.
2. 독자가 공식적인 옵저버가 된다.
3. 주제 객체의 값이 바뀐다 -> 모든 옵저버들이 연락을 받는다.
4. 한 옵저버가 옵저버 목록에서 탈퇴하고 싶다고 요청한다
5. 탈퇴를 요청한 옵저버가 빠진다
6. 주제 객체의 값이 바뀐다.
-> 탈퇴 요청한 옵저버를 제외한 나머지가 연락을 받는다.
7. 옵저버 패턴에서는 주제와 옵저버가 느슨하게 결합되어 있는 객체 디자인을 제공한다!
주제가 옵저버에 대해서 아는 것은 옵저버가 특정 인터페이스를 구현한다는 것 뿐이다.
옵저버는 언제든지 새로 추가할 수 있다.
새로운 형식의 옵저버를 추가하려고 할 때도 주제를 전혀 변경할 필요가 없다.
주제와 옵저버는 서로 독립적으로 재사용할 수 있다.
주제나 옵저버가 바뀌더라도 서로한테 영향을 미치지 않는다.
느슨하게 결합하는 디자인을 사용하면 변경 사항이 생겨도 무난히 처리할 수 있는
유연한 객체지향 시스템을 구축할 수 있다.
객체 사이의 상호의존성을 최소화할 수 있기 때문이다.
8.
9. 데코레이터 패턴
객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 파생 클래스를 만
드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.
10. 데코레이터 패턴의 원칙
1. 클래스는 확장에 대해 열려 있어야 하지만 코드 변경에 대해는 닫혀 있어야 한
다.(OCP)
2. 데코레이터의 기본 클래스는 자신이 장식하고 잇는 객체의 기본 클래스와 같다.
3. 한 객체를 여러 개의 데코레이터로 감쌀 수 있다.
4. 데코레이터는 자신이 장식하고 잇는 객체에게 어떤 행동을 위임하는 것 외에 원하
는 추가 적인 작업을 수행할 수 있다.
5. 객체는 언제든 감쌀 수 있기 때문에 실행 중에 필요한 데코레이터를 마음대로 적용
할 수 있다.
11. 전략 패턴의 원칙
1. 애플리 케이션에서 달라지는 부분을 찾아내고, 달라지지 않는
부분으로부터 분리시킨다. (캡슐 화)
2. 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다. (유연성)
3. 상속보다는 구성을 활용한다. (has – a)
15. SimplePizzaFactory에서는 피자를 생성하기만 하면 됨.
PizzaStore에선 생성자에 팩토리 객체 전체가 전달 됨.
New 연산자 대신 팩토리 객체에 있는 CreatePizza 함수를 사용했기 때문에 인스턴스를 만들 필요 X
16. 간단한 팩토리는 디자인 패턴이라고 할 수 없다..
위에 예제는 팩토리 패턴에 대한 이해를 위해 짚고 넘어가는게 좋기 때문
디자인 패턴인 ‘팩토리 메서드 패턴’을 설명하기 위해 필요
17. 객체를 생성하기 위한 인터페이스를 정의하는데
어떤 클래스의 인터페이스를 만들지는 서브 클래스에서 결정한다.
팩토리 메서드 패턴
18. PizzaStore 클래스의 주문 과정은 모든 피자 가게에서 동일하게 이루어진다고 할 때,
달라지는 것은 생성이다.
PizzaStore의 서브 클래스를 만들어 그 내부에서 CreatePizza()를 구현하면,
자식 클래스마다 다른 스타일의 피자를 생성할 수 있게 된다.
19.
20.
21.
22. 모든 팩토리 패턴에서는 객체 생성을 캡슐화 한다. 팩토리 메소드 패턴에서는
서브 클래스가 어떤 클래스를 만들지 결정하게 함으로써 객체 생성을 캡슐화 한다.
팩토리 메소드 패턴에서는 어떤 클래스에서 인스턴스를 만드는 일을 서브 클래스한테 넘긴다.
23. 싱글턴 패턴
해당 클래스의 인스턴스가 하나만 만들어지고, 어디서든지 그 인스턴스에 접
근 할 수 있도록 하기 위한 패턴.
24. 싱글턴 패턴의 과정
1. 클래스 내부에 private으로 생성자를 선언해 어느곳에서도 이 클래스의 객체를 만들
수 없게 했다.
2. public static MyClass getInstance() { return new MyClass;}로 객체를 가져올 수 있
게 했다.
3. 하지만 여전히 단하나의 객체는 아니다.
4. Public static MycClass uniqueMyClass; 변수를 만들고 getInstance() 에서 if() 조건
문을 통해 null 인지 체크해 단하나의 객체만 생성 되도록 했다.
-클래스에서 단 하나 뿐인 객체를 관리하고 다른 어떤 클래스에서도 자신의 객체를 만
들지 못하게 한다. 객체가 필요하다면 반드시 자신을 거쳐야 한다.
-요청이 들어오면 하나 뿐인 객체를 건네 준다.
25. 싱글턴 패턴의 주의사항
1. 멀티 스레드 일 때 호출 순서의 문제로 싱글턴 객체가 2개 생길 수 있다.
2. 이를 해결하기위해 synchronized 를 사용하여 2번 째 스레드를 대기 시킬 수 있지
만 속도가 100배나 차이 나게 될 수 있다.
3. 속도가 중요하지 않다면 그냥 위 방식을 사용하자. 대신 동기화를 싱글턴 객체 최소
생성시 한번만 하게 한다.
4. 속도가 문제가 될 것 같다면 그냥 인스턴스를 처음부터 만들어 두자.
26. 커맨드 패턴
요청 자체를 캡슐화 하는 것
이를 통해 서로 다른 사용자를 매개변수로 만들고, 요청을 대기시키거나 로깅
하며, 되돌릴 수 있는 연산을 지원한다.
29. 커맨드 패턴의 장단점
작업을 요청하는 객체와 실제 작업을 하는 객체를 분리 시킨다
다양한 요구를 쉽게 추가할 수 있다.
자잘한 클래스가 많이 생성된다.
30. 어댑터 패턴
한 클래스의 인터페이스를 클라이언트에서 사용하고자 하는 다른 인터페이스로 변환할
때 사용한다. 어댑터 패턴을 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는
클래스 들을 연결해서 쓸 수 있다.
31. 어댑터 패턴의 특징
1. 인터페이스를 클라이언트에서 요구하는 형태의 인터페이스에 적응 시켜준다!
2. 적응할 타겟의 인터페이스 형식으로 기존 인터페이스를 구현해 준다.
3. 어댑터는 결국 인터페이스의 크기에 구현하는 복잡도가 증가한다.
4. 서로 다른 인터페이스를 결과적으로 호환 시켜 주는 것이다.
32. 어댑터 패턴의 특징
1. 인터페이스를 클라이언트에서 요구하는 형태의 인터페이스에 적응 시켜준다!
2. 적응할 타겟의 인터페이스 형식으로 기존 인터페이스를 구현해 준다.
3. 어댑터는 결국 인터페이스의 크기에 구현하는 복잡도가 증가한다.
33. 퍼사드 패턴
어떤 서브 시스템의 일련의 인터페이스에 대한 통합된 인터페이스를 제공한다. 퍼사드
에서 고 수준의 인터페이스를 정의하기 때문에 서브 시스템을 더 쉽게 사용 할 수 있다.
34. 퍼사드 패턴의 원칙
1. 최소 지식 원칙을 따르자 – 정말 친한 친구 하고만 이야기 하자.
2. 객체 자체의 메소드를 호출하자
3. 메소드에 매개변수로 전달된 객체의 메소드를 호출하자
4. 그 메소드에서 생성하고나 인스턴스로 만든 객체의 메소드를 호출하자
5. 그 객체에 속하는 구성소의 메소드를 호출하자.
-시스템에 한부분을 고쳤을 때 줄줄이 다 고치지 않으려면 위 원칙을 자주 고려하자
35. 퍼사드 패턴의 원칙
1. 최소 지식 원칙을 따르자 – 정말 친한 친구 하고만 이야기 하자.
2. 객체 자체의 메소드를 호출하자
3. 메소드에 매개변수로 전달된 객체의 메소드를 호출하자
4. 그 메소드에서 생성하고나 인스턴스로 만든 객체의 메소드를 호출하자
5. 그 객체에 속하는 구성소의 메소드를 호출하자.
-시스템에 한부분을 고쳤을 때 줄줄이 다 고치지 않으려면 위 원칙을 자주 고려하자
36. 템플릿 메소드 패턴
상위 클래스에서 처리의 흐름을 제어하며, 하위 클래스에서 처리의 내용을 구체화한다.
여러 클래스에 공통되는 사항은 상위 추상 클래스에서 구현하고, 각각의 상세부분은 하
위 클래스에서 구현한다.
코드의 중복을 줄이고, 리팩토리에 유리한 패턴으로 상속을 통한 확장 개발 방법
42. 이터레이터 패턴의 원칙
1. 객체를 컬렉션(자료구조 등)에 집어 넣는 방법은 정말 다양하다. 객체를 저장하는
방식은 보여주지 않으면서 클라이언트로 하여금 객체들에게 일일이 접근 할 수 있
게 하고 싶다.
2. 객체의 컬렉션에 대한 반복작업을 처리하는 방법을 캡슐화 한 iterator 객체를 만들
자.
3. 클래스를 바꾸는 이유는 한 가지 뿐이어야 한다. (만일 클래스 내에서 반복 작업 메
소드 와 집합체를 관리하는 원래의 역할 두개가 모두 있다면 이 두개에 의해 클래스
가 바뀔 우려가 있다.)
4. 클래스를 고치는 것은 최대한 피해야 한다. 또한 한 클래스는 한 가지 역할을 해야
한다.
43. 이터레이터 패턴의 원칙
1. 객체를 컬렉션(자료구조 등)에 집어 넣는 방법은 정말 다양하다. 객체를 저장하는
방식은 보여주지 않으면서 클라이언트로 하여금 객체들에게 일일이 접근 할 수 있
게 하고 싶다.
2. 객체의 컬렉션에 대한 반복작업을 처리하는 방법을 캡슐화 한 iterator 객체를 만들
자.
3. 클래스를 바꾸는 이유는 한 가지 뿐이어야 한다. (만일 클래스 내에서 반복 작업 메
소드 와 집합체를 관리하는 원래의 역할 두개가 모두 있다면 이 두개에 의해 클래스
가 바뀔 우려가 있다.)
4. 클래스를 고치는 것은 최대한 피해야 한다. 또한 한 클래스는 한 가지 역할을 해야
한다.
44. 이때 문제가 생겼다.
1. 객체를 컬렉션(자료구조 등)에 집어 넣는 방법은 정말 다양하다. 객체를 저장하는
방식은 보여주지 않으면서 클라이언트로 하여금 객체들에게 일일이 접근 할 수 있
게 하고 싶다.
2. 객체의 컬렉션에 대한 반복작업을 처리하는 방법을 캡슐화 한 iterator 객체를 만들
자.
3. 클래스를 바꾸는 이유는 한 가지 뿐이어야 한다. (만일 클래스 내에서 반복 작업 메
소드 와 집합체를 관리하는 원래의 역할 두개가 모두 있다면 이 두개에 의해 클래스
가 바뀔 우려가 있다.)
4. 클래스를 고치는 것은 최대한 피해야 한다. 또한 한 클래스는 한 가지 역할을 해야
한다.
45. 컴포지트 패턴
객체들을 트리구조로 구성하여 부분과 전체를 나타내는 계층구조로 만들 수
있다. 이 패턴을 이용하면 클라이언트에서 개별 객체와 다른 객체들로 구성된
복합 객체를 똑같은 방법으로 다룰 수 있다.
46. 컴포지트 패턴의 특징
1. 객체의 구성과 개별 객체를 노드로 가지는 트리형태로 객체를 구축 할 수 있다. (자
식이 있는 노드, 자식이 없으면 잎(leaves))
2. 이런 복합구조를 사용하면 복합 객체와 개별 객체에 대해 똑같은 작업을 적용할 수
있다.
3. 대부분의 경우에 복합 객체와 개별 객체를 구분할 필요가 없어진다.
4. 하지만 한 클래스에서 한 역할만 해야 하는 원칙을 깨고 있다.(잎과 노드에 서로 다
른 역할을 다 하고 있기 때문)
5. 대신 투명화를 확보한 패턴이다. 인터페이스의 자식들을 관리하기 위한 기능과 잎
으로써의 기능을 전부 집어넣어 복합 객체와 잎 노드를 똑같은 방식으로 처리할 수
있기 때문에 클라이언트 입장에서는 복합 객체인지 잎인지 투명화 되는 것이다.
47. 컴포지트 패턴의 특징
1. 객체의 구성과 개별 객체를 노드로 가지는 트리형태로 객체를 구축 할 수 있다. (자
식이 있는 노드, 자식이 없으면 잎(leaves))
2. 이런 복합구조를 사용하면 복합 객체와 개별 객체에 대해 똑같은 작업을 적용할 수
있다.
3. 대부분의 경우에 복합 객체와 개별 객체를 구분할 필요가 없어진다.
4. 하지만 한 클래스에서 한 역할만 해야 하는 원칙을 깨고 있다.(잎과 노드에 서로 다
른 역할을 다 하고 있기 때문)
5. 대신 투명화를 확보한 패턴이다. 인터페이스의 자식들을 관리하기 위한 기능과 잎
으로써의 기능을 전부 집어넣어 복합 객체와 잎 노드를 똑같은 방식으로 처리할 수
있기 때문에 클라이언트 입장에서는 복합 객체인지 잎인지 투명화 되는 것이다.
48. State Pattern
어떤 객체의 내부 상태가 계속 추가될 가능성이 있을 때 새로운 상태의 추가도
쉽게 만들어주고, 추가된 상태를 포함해서 객체의 상태 변화 시 기존 소스코드
변경 없이 행위 수행 변경이 가능하도록 객체 상태 정보를 클래스 상속 구조로
정의해서 사용하는 방식
객체의 내부 상태가 바뀜에 따라 객체의 행동을 바꿀 수 있다.
49. State Pattern
사용 용도 및 장점
- 객체의 상태에 따라서, 동일한 동작이라도 다른 처리를 해야할때 사용한다.
- 하나의 객체에 여러가지의 상태가 존재할때 보통 if문이나 switch문으로 분기를 해서 결과를 처리
신규 상태가 존재할때마다 코드를 수정
-> 객체의 상태를 클래스화해서 그것을 참조하게 하는 식으로 소스의 변화를 최소화
50.
51. 프록시 패턴
어떤 객체에 대한 접근을 제어하기 위한 용도로 대리인이나 대변인에 해당하
는 객체를 제공하는 패턴.
(원격 객체, 생성하기 힘든 객체, 보안이 중요한 객체와 같은 다른 객체에 대한
접근을 제어하는 대변자 객체를 만들 수 있다.)
52. 프록시 패턴의 기본 형태
1. 원격 프록시 설계의 예로 프록시 패턴의 형태를 알 수 있다.
53. 프록시 패턴의 다양한 형태
1. 원격 프록시 (위의 예)
2. 가상 프록시 ( 생성하는데 많은 비용이 드는 객체를 대신 하는 역할을 한다. 실제로
진짜 객체가 필요하게 되기 전까지 객체의 생성을 미루는 기능도 한다.)
-클라이언트에서 진짜 객체가 아닌 프록시를 사용하도록 만드는 가장 흔한 방법은 진
짜 객체의 인스턴스를 생성해서 리턴하는 팩토리를 사용하는 방법이다.
(CD커버 이미지를 인터넷 상황에 따라 백그라운드에서 불러오면서 대기 메시지를 띄
우는 등)
3. 동적 프록시 (실제 프록시 클래스가 실행 중에 생성되는 것을 동적 프록시라고 한다.
동적 프록시는 특이하게도 2개의 클래스로 구성된다.)
-proxy와 proxy 객체에 대한 모든 메소드 호출에 응답(InvocationHandler 이다)하는 핸
들러 이다. 프록시가 메소드 호출을 받으면 핸들러에게 진짜 작업을 요청하게 되는 것
이다. (예는 사용자의 권한에 따라 다른 페이지를 보여주고 싶을때)
54. 프록시 패턴의 다양한 형태
1. 원격 프록시 (위의 예)
2. 가상 프록시 ( 생성하는데 많은 비용이 드는 객체를 대신 하는 역할을 한다. 실제로
진짜 객체가 필요하게 되기 전까지 객체의 생성을 미루는 기능도 한다.)
-클라이언트에서 진짜 객체가 아닌 프록시를 사용하도록 만드는 가장 흔한 방법은 진
짜 객체의 인스턴스를 생성해서 리턴하는 팩토리를 사용하는 방법이다.
55. 프록시 패턴의 다양한 형태
1. 방화벽 프록시: 일련의 네트워크 자원에 대한 접근을 제어해준다. (나쁜 클라이언트
들로부터)
2. 스마트 레퍼런스 프록시: 주 객체가 참조될 때마다 추가 행동을 제공한다. (객체에
대한 참조수를 세는 등)
3. 캐싱 프록시: 비용이 많이 드는 작업의 결과를 임시로 저장해준다. (여러 클라이언트
에 결과를 공유해 줘서 계산 시간 또는 네트워크 지연시간을 줄이는데 사용한다.)
4. 동기화 프록시: 여러 스레드에서 주 객체에 접근하는 경우에 안전하게 작업을 처리
할 수 있게 해준다.
5. 복잡도 숨김 프록시: 복잡한 클래스들의 집합에 대한 접근을 제어하고, 복잡도를 숨
겨준다. 퍼사드 프록시라고도 한다.
60. 패턴과 함께 하는 삶
디자인 패턴에 대한 정리를 해보고 실전에서의 패턴은 어떻게 접근해야 하는
지 살펴보자.
61. 디자인 패턴이란?
-디자인 패턴이란 특정 컨텍스트 내에서 주어진 문제에 대한 해결 책이다!
(컨텍스트): 패턴이 적용되는 상황, 반복적으로 일어날 수 있는 상황을 말한다.
(문제): 그 컨텍스트 내에서 이루고자 하는 목적 또는 제약 조건을 뜻한다.
(해결책): 이 바로 우리가 찾아내야 하는 것이다. 일련의 제약 조건 내에서 목적을 달성
할 수 있는 일반적인 디자인을 뜻한다.
62. 디자인 패턴의 주의 사항
1. 패턴을 조금 변형해도 좋다 하지만 문서화해 다른 개발자와의 소통을 돕자
2. Gof 등의 좋은 디자인패턴 책도 공부하자
3. 누구나 새로운 패턴을 발견할 수 있지만, 이를 위해서는 기본 것들에 충실해야 한다.
4. 3의 규칙: 패턴이 실전 문제 해결에 세 번 이상 적용되지 않는다면 실패한 패턴이다.
63. 디자인 패턴의 요점
1. 최대한 단순하게 해결 하려 노력하자.
2. 패턴이 만병 통치약은 아니다!
3. 간단한 해결책이 있다면 패턴 사용은 충분히 고려해 봐야한다.
4. 리팩토링: 코드의 구조를 개선하기 위해 코드를 변경하는 과정을 뜻한다. 행동을 변
경하는 것이 아닌 구조를 개선하는데 있다.
5. 안티 패턴도 있다! (나쁜 해결책들은 경험이 되고 문서화해 공유하자)
