디자인 원칙
애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리한다.
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
상속보다는 구성을 활용한다.
서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결한하는 디자인을 사용해야 한다.
클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다.(OCP : Open-Closed Principle)
추상화된 것에 의존하도록 만들어라. 구상클래스에 의존하도록 만들지 않도록 한다.
최소 지식 원칙 - 정말 친한 친구하고만 얘기하라.
객체 자체
메서드에 매개변수로 전달된 객체
그 메서드에서 생성하거나 인스턴스를 만든 객체 / 4. 그 객체에 속하는 구성 요소)
헐리우드 원칙 - 먼저 연락하지 마세요. 저희가 연락 드리겠습니다.
클래스를 바꾸는 이유는 한 가지 뿐이어야 한다.
나중에 어떻게 바뀔 것인가?
주의점
디자인 패턴의 과다한 사용은 불필요하게 복잡한 코드를 초래할 수 있다.
항상 가장 간단한 해결책으로 목적을 달성할 수 있도록 하고, 반드시 필요할 때만 디자인 패턴을 적용하자.
다른 개발자들이 그 코드를 볼 때 무엇을 어떻게 구현했는지 훨씬 빠르게 이해할 수 있도록 하자.
코딩할 때 어떤 패턴을 사용하고 있는지 주석으로 적어주자.
클래스와 메서드 이름을 만들 때도 사용 중인 패턴이 분명하게 드러날 수 있도록 해보자.
디자인 패턴
전략 패턴(Strategy Pattern) - 캡슐화 (구현보다는 인터페이스, 상속보단 구성)
옵저버 패턴(Observer Pattern) - 주제 객체가 바뀌면 옵저버 객체가 자동 갱신되는 방식 (객체간 의존성 없이 느슨하게 연결함)
데코레이터 패턴(Decorator Pattern) - 서브 클래스를 만들어 기능을 확장 하는 방식 즉, 파라미터 객체 전달(확장에 대해 열려 있어야 하고 코드 변경에 있어서는 닫혀 있어야 함)
팩토리 패턴(Factory Pattern) - 인스턴스를 동적으로 생성
싱글턴 패턴(Singleton Pattern) - 하나의 인스턴스만 만들고 어디서든 접근 (유일무이한 객체를 필요한 타이밍에 생성)
커맨드 패턴(Command Pattern)
어댑터 패턴(Adapter Pattern)
퍼사드 패턴(Facade Pattern)
템플릿 메서드 패턴(Template Method Pattern)
이터레이터 패턴(Iterator Pattern)
컴포지트 패턴(Composite Pattern)
스테이트 패턴(State Pattern)
프록시 패턴(Proxy Pattern)