DAY 57. SOLID 원칙

• 문제발생

request 로 전달받은 값에 대한 검증을 contoller 에서하는게 맞는지 service 에서 하는게 맞는지에 관한 포스팅을 보게되었다. controller 에서 검증을 하는 것은 SOLID 원칙 중 S '단일 책임의 원칙' 을 위배한다고 하는데, 한달전에 배웠던 SOLID 원칙이 하나도 기억이 나지 않았다.

• 시도

복습

• 해결방안

한달 전 자료와 참고 자료를 바탕으로 복습하자.

• 알게 된 것

- SOLID 원칙이란 객체지향 프로그래밍의 특성과 장점을 최대한 끌어올리기 위한 '어떻게 설계하는가?' 에 설계 원칙 이라고 할 수 있다.

- 간단히 말해 '객체지향 프로그래밍의 효율의 정점을 위한 5가지 설계원칙' 이라 할 수 있다.

 

1. SRP (Single Responsibility Principle) 단일 책임 원칙 [1 클래스, 1 책임]

• 클래스는 단 한개의 책임을 가져야 한다.
• 클래스를 변경하는 이유는 단 하나여야 한다.
• 위를 지키지 않으면, 하나의 책임의 변경에 의해 다른 책임과 관련된 코드에 영향을 미칠 수 있다. (유지보수 비효율)

2. OCP (Open-Closed Principle) 개방-폐쇄 원칙 [추상화, 상속]

• 확장은 열려있고, 변경에는 닫혀 있어야 한다.
• 기존코드 변경 없이 기능을 수정하거나 추가 할 수 있도록 설계해야 한다.
• 추상화(인터페이스) 와 상속 (다형성) 등을 통해 구현이 가능하다. 변화하는 부분을 추상화해서 기존 코드를 수정하지 않고도 기능을 확장할 수 있도록 함으로써 유연성을 높인다.

3. LSP (Liskov Substiution Principle) 리스코프 치환 원칙 [상속관계 철저히]

• 하위 타입 객체는 상위 타입 객체에서 가능한 행위를 수행 할 수 있어야 한다.
• 상속관계인 클래스를 상속관계로 설정해야지 위반해서는 안된다.
• LSP 위반은 즉 OCP 위반을 의미한다.

4. ISP (Interface Segreation Pinciple) 인터페이스 분리 원칙 [클라이언트가 필요로 하는 인터페이스는 분리한다.]

• 클라이언트는 자신이 사용하는 메소드에만 의존해야한다.
• 하나의 클래스는 자신이 사용하지 않는 인터페이스는 구현해서는 안된다.
• 인터페이스는 해당 인터페이스를 사용하는 클라이언트를 기준으로 잘게 분리되어야 한다.
• 각 클라이언트는 필요로 하는 인터페이스를 분리해서 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 한다.

5. DIP (Dependecy Inversion Principle) 의존 역전 원칙 [구체화된 클래스보다 추상 클래스나 인터페이스 의존해야한다.]

• 의존 관계를 맺을 때, 변하기 쉬운 것 (구체적인 것) 보다는 변하기 어려운 것 (추상적인 것) 에 의존해야한다.

정리!

SRP, ISP 는 객체가 커지는 것을 막아준다. 한 기능의 변경이 다른 곳 까지 영향을 미치는 것을 최소화하고 기능 추가 및 변경에 용이하도록 만든다.

 

LSP 와 DIP 는 OCP 를 서포트한다. 변화되는 부분을 추상화 할 수 있도록 도와주는 원칙이 DIP, 다형성 구현을 도와주는 원칙이 LSP 이다.

 

[결론]

 

1.SRP : 1클래스 1책임

2.OCP : 추상화, 상속

3.LSP : 상속관계 철저히

4.ISP : 인터페이스는 분리한다.

5.DIP : 구체화된 클래스보다 추상 클래스, 인터페이스에 의존한다.