메인 프로젝트에서 작성해둔 코드를 SOLID 원칙에 따라 리팩토링 해보려고 한다.
프로젝트 진행 시에, 멘토님께서 SOLID를 외우기 보다는 체득해서 어떻게 사용했고 이를 코드에 어떻게 적용했는지가 중요하다고 하셨다.

그래서 이번 주에는 SOLID를 체득하고, 이를 적용해보는 시간을 갖으려고 한다.

우선 SOLID에 대한 이해부터 제대로 해보자!

SOLID

SOLID 원칙은 객체 지향 프로그래밍 및 설계의 기본 원칙이다.

그렇다면 객체 지향 프로그래밍에 대해서 빠르게 다시 집고 넘어가자.

객체 지향 프로그래밍

객체 지향 프로그래밍은 수많은 사람들이 고민하고 시행착오를 겪으면서 만든 프로그래밍 방식이다.

• 컴퓨터 프로그램을 명령어의 목록이라고 보는 절차 지향 방식과 달리, 여러 개의 독립된 단위인 객체들의 모임이라고 보는 것
• 프로그램을 유연하고, 유지보수하기 쉽게 만들기 때문에 대규모 소프트웨어 개발에 많이 사용된다.

그럼 SOLID 원칙에 대해서 자세히 보자.

1. SRP

• 단일 책임의 원칙(Single Responsibility Principle)
• 한 클래스는 하나의 책임(기능)만 가져야 한다.
• 클래스는 그 책임을 완전히 캡슐화해야 한다.

• 응집력
  • 비슷한 일을 하는 기능 즉, 하나의 책임에 포함되는 기능들이 잘 뭉쳐있다면 높은 응집력을 가진다.
  • 하나의 기능을 변경하는데 수정해야 할 곳이 많다면 응집력이 낮은 것이다.
• 결합도
  • 클래스 간에 의존성이 낮다면, 낮은 결합도를 가진다.
  • 하나의 클래스를 수정하는데 의존하는 다른 클래스를 모두 수정해야 한다면 결합도가 높다.
• SRP를 잘 지키면, 응집력이 높아지고 결합도는 낮아진다.

ex) AOP 생성 - 별도의 부가 기능을 핵심 로직에서 분리했기 때문에 SRP를 잘 지킨 예시이다.

2. OCP

• 개방-폐쇄 원칙 (Open/Closed Principle)
• 소프트웨어 요소(클래스, 모듈, 함수)는 확장에는 열려 있으나, 수정에는 닫혀있어야 한다.
  • 한 모듈을 수정할 때, 그 모듈을 이용하는 다른 모듈까지 줄줄이 고쳐야한다면 이와같은 프로그램은 유지보수하기 어려운 프로그램이다.
    따라서 어떤 소프트웨어의 요소의 수정이 다른 요소의 수정을 유발하지 않도록 해야한다.
  • 개방-폐쇄 원칙이 잘 적용되면, 기능을 추가하거나 변경해야 할 때 이미 제대로 동작하고 있던 원래 코드를 변경하지 않아도, 기존의 코드에 새로운 코드를 추가함으로써 기능의 추가나 변경이 가능하다.
• 추상화가 핵심
  • 추상화: 공통의 속성이나 기능을 묶어 이름을 붙이는 것으로 객체 지향적 관점에서 클래스를 정의하는 것
• 변하는 것(Open)과 변하지 않는 것(Closed)을 잘 구분
  • 변하지 않는 것 -> 인터페이스에 느슨하게 의존하도록 한다.
  • 변하는 것 -> 인터페이스를 구현하여, 코드를 추가한다.

3. LSP

• 리스코프 치환 원칙(Liskov Substitution Principle)
• 프로그램의 객체는 하위 타입의 인스턴스로 치환할 수 있어야 한다.
• subclass의 객체는 superclass의 참조 변수에 대입해서 superclass의 역할을 수행하는데 문제가 없어야 한다.
• OCP 원칙의 기반

4. ISP

• 인터페이스 분리 원칙(Interface Segregation Principle)
• 일반적인 하나의 인터페이스를 조금 더 구체적인 인터페이스로 쪼개는것이 낫다.
• 인터페이스의 단일 책임을 위한 원칙

5. DIP

• 의존관계 역전 원칙 (Dependency Inversion Principle)
• 구체화에 의존하지 않고, 추상화에 의존하는 것
  • 구체 클래스가 추상 클래스에 의존하므로, 의존 관계가 역전된 형태가 된다.
  • 전통적인 의존 관계: 상위 계층이 하위 계층에 의존
  • 전통적인 의존 관계를 역전시킨다.
• 의존성 주입은 DIP를 따르는 방법 중 하나

[참고]
객체지향 설계 원칙
https://ko.wikipedia.org/wiki/SOLID_(%EA%B0%9D%EC%B2%B4_%EC%A7%80%ED%96%A5_%EC%84%A4%EA%B3%84)
SOLID 원칙

---

리팩토링

• SRP에 따라, 한 클래스가 하나의 책임만을 가지는지 확인한다.
• OCP에 따라, 추상화가 잘 되었는지를 확인한다.
  • 인터페이스를 통해 추상화하기
  • 현재 코드는 추상화가 잘 되어있진 않을 것이다. 아마 중복도 많고 그냥 구현만 해뒀을 것 같은데 이를 수정해보자.
• LSP에 따라, subclass와 superclass로 다시 리팩토링해보자.
  • 현재 코드는 상속이나 추상화가 잘 없다.
  • 언제 상속을 써야할지, 언제 인터페이스를 써야할지에 대해서 스스로 정의해보기
• ISP에 따라, 현재 구현되어 있는 인터페이스는 무엇인지, 이를 좀 더 구체적인 인터페이스로 쪼갠다면 어떻게 해야하는지 확인한다.
• DIP에 따라, 의존 관계가 역전되었는지 확인한다.

---

1. Comment 중복

게시글, 모집글에 대한 댓글 기능을 구현하려고 할 때,
https://okky.kr/questions/1402395
https://truehong.tistory.com/74
https://itvillage.tistory.com/entry/%EA%B0%9D%EC%B2%B4%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84-%EC%9B%90%EC%B9%99-SOLID-%EC%9B%90%EC%B9%99