SOLID 원칙

SOLID 원칙

객체지향 설계를 위한 5대 원칙인 SOLID에 대해 알아보자

들어가기 전에

• 우선 참고 블로그를 통해 개념을 이해하고, 추후 직접 예제코드를 통해 적용하고 더 구체적으로 작성해보도록 한다.

객체지향 5대 원칙 : SOLID

• 객체지향 디자인 원리를 사용하면 더욱 유지보수하기 쉽고, 유연하고, 확장이 쉬운 소프트웨어를 개발 할 수 있다.
• SOLID 원칙은 자신의 클래스 내부의 응집도는 높이고, 다른 클래스와의 결합도는 낮추는 원칙을 객체지향 관점에서 도입한 것이다.

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

• 하나의 클래스는 한 가지의 책임(기능)만을 가져야 하며 변경하는 이유는 단 하나의 이유여야 한다.
• 즉, 클래스와 관련된 책임만 갖도록 하여 응집도를 높인다.
• 추상화와도 관련이 깊다.

OCP(Open-Closed Principle, 개방-폐쇄 원칙)

• 확장에는 열려있고 변경에는 닫혀있어야 한다.
• 공통 기능을 하는 인터페이스를 부모로 두고 이를 상속받아 구현하는 방식을 예로 들 수 있겠다. (Payment - Cash, Card)
• 확장성 있는 설계와 관련이 깊다.

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

• 베이스 클래스가 서브 클래스로 치환되어도 동일한 동작을 보장해야 한다. (Base object = new Sub())
• 정사각형과 직사각형 예제가 있다. 논리적으로 정사각형은 직사각형에 포함되지만, 행위의 관점(넓이를 구하는 메서드)에서는 정사각형은 직사각형을 상속받을 수 없다.
• 해결책은 더 상위 클래스인 도형이라는 클래스를 직사각형과 정사각형이 각각 상속받아 오버라이드 한다.
• 얼마나 상속구조를 잘 설계했는지를 말한다. 상속은 계층구조가 아니고 확장구조이다.

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

• 인터페이스는 범용적으로 구현하기보다 사용에 맞도록 분리해서 설계해야 한다.
• 인터페이스를 상속받은 하위 클래스에서 사용하지 않는 메서드가 생기면 안된다.
• 여러 메서드가 포함된 하나의 범용적인 인터페이스보다는 여러개의 구체적인 인터페이스를 독립적으로 생성한다.
  • 다중 인터페이스 상속으로 복합하여 필요한 클래스를 구현 할 수 있다.

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

• 의존관계를 맺을 때 구체적인 클래스보다는 인터페이스나 추상 클래스와 같이 상위 클래스와 관계를 맺어야 한다.

  

• 구체화된 하위 클래스의 경우 상대적으로 변화가 많기 때문에 코드 수정이 빈번해진다.

• OCP와도 철학이 일치한다.

References

• https://sabarada.tistory.com/36
• https://limkydev.tistory.com/77
• https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99
• https://cheese10yun.github.io/spring-solid-dip/