SOLID
단일 책임의 원칙
Single Responseiblity Principle
Ex) 어떠한 변경이 있을때 변경 요소가 적으면 적을수록 잘 준수한 것
영역을 나누는 것도 준수하기 위한 노력인것
개방 - 패쇄 원칙
Open / Closed Principle
확장에서는 열려있으나 변경에는 닫혀있어야한다
무슨 쌉소리인가 싶다.
영한님의 설명으로 이해하자면
자동차 카테고리에 종류가 추가되는건 확정성이지만
자동차에 대한 개념 자체가 변하는건 변경이라 봐야한다.
OCP가 깨지는 상황 : 클라이언트 코드를 변경해야하는 상황
객체를 생성 , 연관 관계를 맺어주는 별도의 조립 설정자가 필요하다
이거를 Spring 해준다
리스코프 치환 원칙
Liskov substitution principle
악셀을 밝으면 앞으로 가야하는데 뒤로가게 하는 등우 "규약"을 어긋나는 행동을 하지 않는 것
인터페이스를 무시할 수는 없다
인터페이스 분리 원치
Interface segregation principle
특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 좋다.
기능을 적당한 , 명확한 구조의 분리를 해야한다.
의존관계 역전의 원칙
Dependency inversion principle
프로그래머는 추상화에 의존해야지 구체화에 목매면 안된다
이것도 뭔소린가 싶었다.
영한님 말에 따르면 impl 한 구현체보다 interface에 집중하라는 의미
운전자는 자동차라는 개념에 알아야지 , 특정 차량에 집중할 경우 다형성이 떨어진다.
뭐...운전은 할 수 있으니깐
하지만 다형성,DIP에만 의존하면 구현체를 돌릴 수는 없다
Spring은 DIP,OCP를 지원할 수 있도록 지원
- DI(Dependency Injection)
- DI Container
- 비용의 문제가 아니라 개발자의 시간이 문제가 된다고 하신다
- 장점과 단점을 따져 장점이 단점을 뛰어날 경우에만 추상화라는 비용을 감당하자
- 기능에 확장성이 없다고 생각되면 바로 구체화 후 추상화 비용을 절약하도록 하자
영한님의 추천 도서
- 조영은님의 객체지향의 사실과 오해
- 토비의 스프링
- 자바 ORM 표준 JPA 프로그래밍
