클래스 간의 관계와 설계 원칙

Posted by yunki kim on May 10, 2021

SOLID

  -SRP: 단일책임 원칙

  -OCP: 개방폐쇠 원칙

  -LSP: 리스코프 치환 원칙

  -ISP: 인터페이스 분리 원칙

  -DIP: 의존 역전 원칙

 

SRP: Single Responsibility Principle

  -클래스를 변경해야 하는 이유는 단 하나여야 한다.

    -좋은 설계: 모듈의 응집도를 높이고, 결합도를 낮추는 설계

    -단일 책임 원칙: 클래스는 한가지 책임만 갖도록 설계한다

    -만일 클래스에서 두 개의 책임이 존재하면 두개의 클래스로 분리해야 한다. 

 

OCP: Open-Closed Principle

. -확장(상속)에는 열려있어야 하고 변경에는 닫혀있어야 한다.

    -개방폐쇠원칙: 클래스는 확장은 쉽고, 변경의 영향은 받지 않게 설계하자

    -하위 클래스의 특정 기능을 상위 클래스에서 미리 구현하는 것과 같아서 이 기능이 필요 없는 다른 하위 클래스에서 강제로 상속받아야 하는 경우가 발생한다. 따라서 추상 크래스와 구체 클래스를 분리해야 한다. 

  

LSP: Liskov Substitution Principle

.  -기반 클래스는 파생 클래스로 대체할 수 있어야 한다

   -기반 클래스가 들어갈 자리에 파생 클래스를 넣어도 문제없이 잘 동작한다.

   -서브타입(상속받은 하위 클래스-신버전)은 어디에서나 자신의 기반타입(상위 클래스-구버전)으로 교체할 수 있어야 한다.

 

ISP: Interface Segregation Principle

  -하나의 일반적인 인터페이스보다는 구체적인 여러 개의 인터페이스가 낮다

  -클라이언트는 자신이 사용하지 않는 메서드와 의존 관계를 맺으면 안된다 -> 각 클라이언트에 맞는 인터펭시만 분리

  -인터페이스를 분리하게 되면

    -시스템 확장 시 변화의 폭을 필요한 기능에 대한 변경이나 확장으로 제한 가능

    -많은 메서드로 인한 가독성 및 높은 결합도의 문제 해결

DIP: Dependency Inversion Principle

 -클라이언트는 구체 클래스가 아닌 추상 클래스(인터페이스)에 의존해야 한다

 -상속 개념을 적용할 떄 구체 클래스에서 상속을 받는  구조로 설계하지 말라는 것

 -구체 클래스는 추상 클래스보다 변하기 쉽기 때문이다.