[로드맵] 클린 코드 SOLID

🎓 이 글은 인프런에서 제공하는 박우빈님의 "클린 코드 & 테스트 코드 가이드 로드맵" 강의를 수강하면서 정리한 내용을 바탕으로 작성한 글입니다.

https://www.inflearn.com/roadmaps/5699

클린 코드 & 테스트 코드 가이드 로드맵 로드맵 - 인프런

 

---

 

SOLID

객체지향 설계를 이해하기 쉽고 유지보수하기 유연하게 형태로 할 수 있도록 도움을 주는 5가지 원칙

• SRP : Single Responsibility Principle
• OCP : Open-Closed Principle
• LSP : Liskov Substitution Principle
• ISP : Interface Segregation Principle
• DIP : Dependenty Inversion Principle

 

단일책임원칙 SRP : Single Responsibility Principle

하나의 클래스가 하나의 책임만 갖도록 설계를 하라는 원칙

  - 하나의 클래스가 변경 이유가 두가지라면, 해당 클래스의 책임은 2개 이상인 것.

  - 객체가 가진 공개 메서드, 필드, 상수 등은 해당 객체의 단일 책임에 의해서만 변경되어야 함

 

이유 : SRP 를 지키게 되면 높은 응집도를 가지게 되고 낮은 결합도를 가지고 된다.

  - 응집도 : 클래스나 모듈 내에 요소들이 긴밀하게 연관되어 있는 정도

  - 결합도 : 두개 이상의 객체가 협력했을 때 한 객체가 변경되었을때 다른 객체들에 영향을 미치는 정도

 

개방-폐쇄 원칙 OCP : Open-Closed Principle

확장에는 열려있고, 수정에는 닫혀 있어야 한다.

  - 새로운 요구사항이 추가되었을 때, 기존 코드의 변경 없이, 시스템의 기능을 확장할 수 있어야 한다.

어떻게 OCP 를 지킬 수 있나 ? >> 추상화와 다형성을 활용해서 OCP 를 지킬 수 있다. 

 

리스코프 치환 원칙 LSP : Liskov Substitution Principle

리스코프 : 바바라 리스코프(사람 이름)

상속 구조에서 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 치환할 수 있어야 한다.

  - 자식 클래스는 부모 클래스의 책임을 준수하며, 부모 클래스의 행동을 변경하지 않아야 한다.

 

이유 : LSP 를 위반하면, 상속 클래스를 사용할 때 예외가 발생하거나 이를 방지하기 위한 불필요한 타입 체크가 동반될 수 있다. 따라서 상속 구조를 사용하려면 LSP 를 잘 지키는 형태로 구현해야한다.

 

인터페이스 분리 원칙 ISP : Interface Segregation Principle

클라이언트는 자신이 사용하지 않는 인터페이스에 의존하면 안된다. 

  - 인터페이스를 잘게 쪼개는 것이 권장됨(=기능단위로 인터페이스를 잘게 나누어 사용해라)

 

이유 : 인터페이스 하나가 너무 무겁고 여러가지 기능이 합쳐져있게 되면 구현체에서 불필요한 기능까지 구현하게 되어버린다. 불필요한 의존성으로 인해 결합도가 높아지고, 특정 기능의 변경이 여러 클래스에 영향을 미칠 수 있다.

 

의존성 역전 원칙 : DIP : Dependenty Inversion Principle

상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안되고, 둘 모두 추상화에 의존해야 한다는 원칙 (= 추상화 레벨이 높은 쪽의 모듈이 구체 쪽에 가까운 모듈에 직접적으로 의존해서는 안된다. 모두 추상화에 의존하자)

  - 의존성의 순방향 : 고수준 모듈이 저수준 모듈을 참조하는 것

  - 의존성의 역방향 : 고수준, 저수준 모듈이 모두 추상화에 의존하는 것

    - 의존성 : 하나의 모듈이 다른 하나의 모듈을 참조하거나, 직접적으로 생성하거나, 사용하는 것

  - 저수준 모듈이 변경되어도, 고수준 모듈에는 영향이 가지 않는다. 

 

이유 : 저수준 모듈은 자주 변경되는데, DIP 원칙을 지키면 저수준 모듈이 자유롭게 변경되어도 고수준 모듈에는 영향이 가지 않는다.