필자의 해석이 포함되어 있습니다!
실제로 책에서 의도한 의미와는 다를 수 가 있습니다
주의 부탁드립니다 !!

3장 : SOLID 원칙

SRP

• 단일 책임 원칙. Single Responsibility Prinsiple

• 객체는 단 하나의 책임(메서드)만 가져야 한다

산탄총 수술

• 변경에 대하여 여러 클래스를 변경함
• SRP를 지키니 못하면 일어날 수 있는 참사

OCP

• 개방-폐쇄 원칙. Open-Closed Principle
• 기본의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계되어야 한다는 뜻

LSP

• 리스코프 치환 원칙. Liskov Substitution Principle

• 자식 클래스는 부모 클래스의 행위를 수행할 수 있어야 한다

나는 이것을 LG OLED TV 객체가 LG TV 객체의 기능을 동일 수행할 수 있어야 한다고 받아들였다..

LG TV만 영상 보기가 되고 OLED는 안되면 말이 안되니까 !

DIP

• 의존 역전 원칙. Dependency Inversion Principle

스프링 프레임워크의 DI를 생각하면 좋다 ! 최대한 객체의 생성을 외부로 맡기고 조립만 따로 하는 것이다

Toy toy = new Robot(); // 혹은 Lego
Kid kid = new Kid();
kid.setToy(toy);
kid.play();

ISP

• 인터페이스 분리 원칙. Interface Segreation Principle

구현체를 인터페이스를 사용하여 클라이언트와 분리시킨다

클라이언트는 자신이 필요한 기능을 인터페이스를 통해서 선택한다

4장 : 디자인 패턴

디자인 패턴의 이해

• 본래 건축 분야에서 시작됨
  • 각 패턴은 우리 주변에서 자주 반복해서 발생하는 문제와 그 문제를 해결하는 핵심을 기술해 동일한 일을 두 번 다시 하지 않고 해결할 수 있도록 한다.

다양한 문제들이 있다고 할 떄 이 문제를 해결하는 설계들과 해결책 사이에 유사점이 있다.

이것이 바로 패턴인 것.

GoF 디자인 패턴

생성 패턴

• 객체 생성에 관련된 패턴
• 객체의 생성과 조합을 캡슐화

• 객체가 생성되거나 변경되어도 프로그램 구조에 영향을 크게 받지 않도록 유연성을 제공

• 싱글턴, 팩토리 메서드, 추상팩토리
• (책에 없음) 빌더

구조 패턴

• 클래스나 객체를 조합해 더 큰 구조를 만드는 패턴
• 예) 서로 다른 인터페이스를 지닌 2개의 객체를 묶어 단일 인터페이스 제공

• 예) 객체들을 서로 묶어 새로운 기능을 제공하는 패턴

• 컴퍼지트, 데커레이터
• (책에 없음) 퍼사드, 어댑터

행위 패턴

• 옵서버, 스테이트, 스트래티지, 템플릿 메서드, 커맨드

• (책에 없음) 비지터

• 스트래티지, 스테이트, 커맨드, 비지

내가 학습할 디자인 패턴과 그 순서는?

참조 카운트가 0인것부터 격파한다 !

• 싱글턴
• 스트래티지
• 스테이트
• 템플릿 메서드
• 팩토리 메서드
• 추상 팩토리