SRP
Single Responsibility Principle (단일 책임 원칙)
한 클래스는 하나의 책임만 가져야 한다.
책임의 기준이 모호할 수도 있는데, 중요한 기준은 변경이다.
변경이 필요할 때 파급효과가 적으면 단일 책임 원칙을 잘 따른것이라고 할 수 있다.
OCP
Open/Closed Principle (개방-폐쇄 원칙)
소프트웨어 요소는 확장에는 열려있으나, 변경에는 닫혀있어야 한다.
LSP
Liskov Substitution Principle (리스코프 치환 원칙)
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다. 즉, a의 기능을 담당한 인터페이스 규약이 있다면 그 구현체 또한 규약을 맞춰야 한다.(기능적으로 보장해야 한다)
ISP
Interface Segregation Principle (인터페이스 분리 원칙)
특정 클라이언트를 위한 인터페이스에서, 범용으로 쓰이는 하나의 인터페이스보다 여러개의 인터페이스가 낫다.
인터페이스를 분리함으로써 클라이언트의 분리가 가능해지고, 유지보수가 쉬워진다.
DIP
Dependency Inversion Principle (의존관계 역전 원칙)
구체화에 의존하지 않고 추상화에 의존해야한다.
즉, 클라이언트 코드가 구현 클래스에 의존하는것이 아니라 인터페이스에 의존해야 한다는 것이다.
역할과 구현의 분리와 비슷하다. 자동차를 예시로 들어보자.
운전자가 자동차의 기능에 대해 알고있기만 하면 된다. 운전자는 자동차에 대해 알 필요가 없다. 단지 앞으로 가고 뒤로 가고 멈추고 이런 기능들만 알고있으면 자동차가 바뀌어도 운전자는 운전을 할 수 있다. 이처럼 시스템 또한 언제든지 대체 가능하도록 설계해야 한다. 이것이 가능하려면 구현에 의존하는 것이 아닌, 역할에 의존해야 한다.
다형성으로 OCP를 충족시키려고 해도, 클라이언트 코드의 변경이 불가피하다. 왜냐하면 클라이언트가 인터페이스에 의존하고 있더라도 구현 클래스에도 의존하고있기 때문이다. 이것은 또한 DIP를 위반하게 된다.
따라서 OCP와 DIP를 위반하지 않으려면 다형성 말고도 다른 어떤 추가적인 기능이 있어야 하는데, 그 역할을 스프링이 해준다.
좋은 객체지향 설계를 위해서 필요한 조건들이라고 하는데, 읽다보면 소프트웨어에서의 좋은 설계라는 것은 어쩌면 메인보드와 비슷한 것 같다. 램이 부족하면 램카드를 추가로 꽂기만 하면 되고, 그래픽 카드를 바꿔서 꽂아도 컴퓨터는 잘 돌아간다. 이렇게 소프트웨어에서도 확장이 쉽고, 바꿔끼우기만 해도 잘 돌아가는 그런 구조를 설계하는 것이 좋은 백엔드 개발자가 아닐까 생각이 든다.
