솔리드 정리

1. SRP( Single Responsibility Principle ), 단일 책임 원칙

• 계산기라는 class가 있음. 더하기 빼기 곱하기 나누기의 기능을 가짐.
• 알람 울리는 기능이 필요해짐
• 계산기 클래스 자체에 알람 메쏘드를 넣지 말라

2. OCP ( Open-Closed Principle ), 개방-폐쇄 원칙 : 코드가 추가될때, 기존코드를 건들지 말라

• 걍 디자인패턴의 strategy pattern 임
• 사자, 호랑이, 오리 클래스가 있을 때, 울음소리라는 공통된 기능을 추상화하여 인터페이스로 두고, 얘를 상속받자

 

3. LSP ( Liskov Substitution Principle ), 리스코프 치환 원칙

• 상위 클래스에서 이미 구현된 메쏘드를 재 오버라이딩 하지 말라
• 왜냐면 상위클래스 형의 변수로 접근하게 되면, 오류가 발생하면 찾기가 빡새짐
•  - ex) class A ,  class B extends A     A b = new B();  b.methodcall();  이렇게 사용시 오류발생할 확률이 큼

4. ISP ( Interface Segregation Principle ), 인터페이스 분리 원칙

• 사용하지 않는 인터페이스는 구현하지 말라 = 인터페이스에 이것저것 때려박지 말라
• ex ) phone interface에 call sms game 등 메쏘드가 필요로하면, 이걸 하나로 때려 박지 말고 call interface, sms interface, game interface로 나눠서 해라(이래야지 기능이 추가될때 기존코드를 건드리지 않음)

5. DIP ( Dependency Inversion Principle ), 의존 역전 원칙

• 객체들이 정보를 주고 받을때는, 어쩔수 없이 의존관계가 형성된다. 이때 파라미터를 추상화된 인터페이스나 abstract 클래스를 쓰자는것
• ex) callMethod(클래스타입) -> callMethod(인터페이스나, 추상클래스 타입)  = 추상성이 낮은 클래스보다 추상성이 높은 클래스와 의존관계를 둬라

기가막힌 곳 출처 : https://victorydntmd.tistory.com/291

[디자인패턴] SOLID 원칙

 

---

클라이언트가(클래스) 서버(멤버변수)에 의존관계를 갖고있고, 서버를 클라이언트에서 직접 생성하면 ocp원칙이 깨진다. 왜냐하면 다른 서버를 바꾸려고 할때, 클라이언트의 소스를 바꿔야 하므로. 그래서 OCP가 깨지는 것이고, 이를 해결하기 위해선 별도의 조립, 설정자가 필요한 것이다.

그리고 저 행위를 해 주는 것이 스프링이 해주는 것이다.(그냥 쉽게 밖에서 IOC컨테이너에 있는 빈으로 주입(DI) 시키는것 생각하면 됨.)