Open j03y14 opened 2 months ago
패턴은 특정 컨텍스트 내에서 주어진 문제의 해결책이다.
반복적으로 일어날 수 있는 상황에서 문제를 해결할 수 있는 일반적인 디자인이다.
패턴 카탈로그를 활용할 때 중요한 것은 패턴 사이의 관계를 파악하는데 중점을 뒀다.
어떤 패턴을 사용할 수 있을까 보다 어떻게 하면 단순하게 해결할 수 있을까를 고민
패턴을 사용할 때는 설계한 디자인에 미칠 영향과 결과를 생각해야 한다.
디자인상의 문제에 적합하다는 확신이 들면 패턴을 도입해야 한다. 간단히 해결되는 문제여도 시스템의 어떤 부분이 변경될거라고 예측되는 상황에서는 디자인 패턴을 적용해야 한다.
리팩터링의 목적은 구조 개선에 있다.
패턴이 없는게 나을 때는 과감히 제거해라.
꼭 필요하지 않은데도 패턴을 적용하지는 말아라.
어떤 문제의 나쁜 해결책
구체적인 부분과 추상화된 부분을 모두 바꿔야 하는 경우에 사용.
밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발할 수 있도록 하는 패턴. 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도 복사할 수 있으려면?
복제되는 객체들에 복제 프로세스를 위임한다.
반복되는 상황에서 지나친 비용이 발생하지 않는 누구나 사용할 수 있는 해결책을 제시해서, 이름을 붙이면 패턴이된다.
책임 연쇄 패턴
여러개의 프록시 패턴처럼 보인다?
인터프리터 패턴← 어떤상황에 쓰는건지 이해가 안됐다
반복적으로 일어날 수 있는 상황에서 문제를 해결할 수 있는 일반적인 디자인이다.
패턴 카탈로그를 활용할 때 중요한 것은 패턴 사이의 관계를 파악하는데 중점을 뒀다.
패턴의 분류
패턴으로 생각하기
어떤 패턴을 사용할 수 있을까 보다 어떻게 하면 단순하게 해결할 수 있을까를 고민
패턴을 사용할 때는 설계한 디자인에 미칠 영향과 결과를 생각해야 한다.
디자인상의 문제에 적합하다는 확신이 들면 패턴을 도입해야 한다. 간단히 해결되는 문제여도 시스템의 어떤 부분이 변경될거라고 예측되는 상황에서는 디자인 패턴을 적용해야 한다.
리팩터링의 목적은 구조 개선에 있다.
패턴이 없는게 나을 때는 과감히 제거해라.
꼭 필요하지 않은데도 패턴을 적용하지는 말아라.
안티패턴
어떤 문제의 나쁜 해결책
기타 패턴
브리지 패턴
구체적인 부분과 추상화된 부분을 모두 바꿔야 하는 경우에 사용.
밀접하게 관련된 클래스들의 집합을 두 개의 개별 계층구조로 나눈 후 각각 독립적으로 개발할 수 있도록 하는 패턴. 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도 복사할 수 있으려면?
복제되는 객체들에 복제 프로세스를 위임한다.