패턴의 분류

생성
- 추상 팩토리
- 싱글턴
- 빌더
- 프로토타입
- 팩토리 메서드
행동
- 템플릿 메서드
- 싱글턴
- 반복자
- 옵저버
- 상태
- 전략
구조
- 데코레이터
- 컴포지트
- 프록시
- 퍼사디
- 어댑터

패턴으로 생각하기

어떤 패턴을 사용할 수 있을까 보다 어떻게 하면 단순하게 해결할 수 있을까를 고민

패턴을 사용할 때는 설계한 디자인에 미칠 영향과 결과를 생각해야 한다.

디자인상의 문제에 적합하다는 확신이 들면 패턴을 도입해야 한다. 간단히 해결되는 문제여도 시스템의 어떤 부분이 변경될거라고 예측되는 상황에서는 디자인 패턴을 적용해야 한다.

리팩터링의 목적은 구조 개선에 있다.

패턴이 없는게 나을 때는 과감히 제거해라.

꼭 필요하지 않은데도 패턴을 적용하지는 말아라.

안티패턴

어떤 문제의 나쁜 해결책

기타 패턴

브리지 패턴

구체적인 부분과 추상화된 부분을 모두 바꿔야 하는 경우에 사용.

밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발할 수 있도록 하는 패턴. https://refactoring.guru/ko/design-patterns/bridge

각각을 독립적으로 개발하고 싶을 때 사용하는듯?

빌더 패턴

제품을 여러 단계로 나눠서 만들도록 제품 생산 단계를 캡슐화 하고 싶을 때 사용

https://refactoring.guru/ko/design-patterns/builder

책임 연쇄 패턴

1개의 요청을 2개 이상의 객체에서 처리해야 할 때

https://refactoring.guru/ko/design-patterns/chain-of-responsibility

요청을 받으면 요청을 처리할지, 다음 핸들러로 전달할지를 결정.

플라이웨이트 패턴

어떤 클래스의 인스턴스 하나로 여러개의 가상 인스턴스를 제공하고 싶을 때 사용.

https://refactoring.guru/ko/design-patterns/flyweight

각 객체에 모든 데이터를 유지하는 대신 여러 객체들간에 공통 부분을 공유해서 리소스를 아끼는 패턴

총알, 미사일, 파편 같은 입자를 별도의 데이터로 표현한다면, 램이 감당하지 못해서 프로그램이 충돌.

여러 입자들이 같은 데이터를 저장한다면, 일정하게 유지되는 부분은 따로 뺀다.

플라이웨이트 패턴은 당신의 프로그램이 많은 수의 객체들을 지원해야 해서 사용할 수 있는 RAM을 거의 다 사용했을 때만 사용하세요.

중재자 패턴

관련된 객체의 통신과 제어를 한 곳으로 집중하고 싶을 때 사용.

https://refactoring.guru/ko/design-patterns/mediator

중재자 패턴은 서로 독립적으로 작동해야 하는 컴포넌트 간의 모든 직접 통신을 중단한 후, 대신 이러한 컴포넌트들은 호출들을 적절한 컴포넌트들로 리다이렉션하는 특수 중재자 객체를 호출하여 간접적으로 협력하게 하라고 제안

메멘토 패턴

객체를 이전 상태로 복구해야 할 때 사용.

프로타입 패턴

https://refactoring.guru/ko/design-patterns/prototype

코드를 클래스에 의존시키지 않고 기존 객체들을 복사할 수 있도록 하는 디자인 패턴. private도 복사할 수 있으려면?

복제되는 객체들에 복제 프로세스를 위임한다.

flagtags / OOP-study

13장. 실전 디자인 패턴 #33