SOLID

SOLID 설계 정신에 대해 알아보자.

SOLID 정신으로 이룰 수 있는 것

• 소프트웨어 설계를 “유연하게” 할 수 있다.
• 유연한 소프트웨어 설계, 즉 추상적인 설계로 커플링을 제거할 수 있다.
• 다만, 추상적으로 될 수록 이해하기 어려워지는 측면이 있기 때문에 유지보수 측면에서 악영향을 줄 가능성도 있다.

도움이 될만한 곳

• 대규모 프로젝트
• 모든 프로젝트에 적용할 수 있다고 생각하지는 말자.
• 직접적/구체적인 것이 더 이해하기 쉽다.
• 규모가 커지면서 유연성이 필요해지는 시점에 도움이 될 것이다.
• 예전에는 외주 개발을 했기 때문에 더 유연성이 중요했다.
  • 즉, 예전에는 SOLID가 더 말이 됐었다.
  • 계약시 스펙에 따라 금액을 산정했었다.
  • 요즘은 작은 요구사항, 잦은 변경사항 때문에 재사용성 높은 설계가 도움이 안될 수 있다.

단일 책임

Only do one thing, One reason to change

• 클래스의 존재 이유는 하나여야만 한다.
• 한 함수에서 너무 많은 일을 하지말라 > 확장
• 그런데 하나라는 의미가 정확히 무엇일까?
• 하나의 개념이 매우 주관적이다.
• 이는 결국 가독성과 관련된 이야기다.
• 사람이 한번에 쉽게 이해할 수 있는 정보의 크기에 대한 이야기다.

단일 책임 정신의 의의

• 이 코드를 보는 대부분의 사람이 이해할 수 있는 크기로 클래스를 만들자.
• 객관적으로 만들겠다고 메서드 개수 제한과 같은 규칙을 정하지 말자.
  • 짧아도 안 읽히는 글이 있고, 길어도 잘 읽히는 글이 있다.
• 이건 사실 함께 일하는 팀에서 정해야하는 부분임

단일 책임 정신을 어겼음을 보여주는 지표

• 클래스 이름에 And가 들어간 경우
• 이건 메서드 이름에도 적용됨

개방-폐쇄

Open for extension, Closed for modification

• 클래스 내부 수정없이 동작을 확장할 수 있어야 한다.
• Switch, if 문을 사용해서 특정 객체를 수정하는 것은 어긋난 예
• 상속 + 다형성을 사용하자는 말
• 이걸 잘 적용하면 단일 책임 정신도 이룰 가능성이 높다.

극단적인 주장

• 한번 만든 클래스는 절대로 바꾸면 안됨
  • 방향성 자체는 좋다.
  • 하지만 바꿔야 하는 상황도 충분히 많다.
  • 바꾸는게 유지보수에 더 좋을 수도
    • breaking change (호환성 문제가 발생할 수 있는 수정사항)
• 모든 문제를 프로그래밍으로 풀지 말자.
  • git과 같은 도구를 사용하면 예전에 사용했던 클래스 지워도 복구 가능함

리스코프 치환

• 자식 개체를 부모 개체로 대체하더라도 동작해야 한다.
• 즉, 부모가 할 수 있었던 일은 자식도 할 수 있어야 한다.

한계

• 매우 맞는 말이지만 어려울 수 있다.
• 모든 자식을 추상화한 것이 부모라 할 수 있다.
• 그런데, 자식을 추가하는 과정에서 부모의 동작을 바꿔야 하는 상황이 있을 수 있다.
• 즉, 추상화된 부모가 항상 맞을 수 없기 때문에 발생하는 문제다.
• 추상화는 구체적인 것들의 공통점을 모아서 만드는 것이다.
• 만약 구체적인 개체가 추가된다면, 이 모든 것의 공통점을 찾아 부모를 고쳐주어야 하는게 자명하다.
• 다만 이게 자주 일어나면 좋지는 않겠다.

인터페이스 분리

큰 인터페이스가 몇 개 있는 것보다는 작은 인터페이스가 많이 있는게 좋다.

• 여전히 이해할 수 있는 정보의 크기의 문제다.
• 작은 단위로 쪼갤 수 있으면 쪼개는게 보통 이해하기 쉽다.
• 역시 밸런스의 문제다.

의존 역전

• 개체끼지 통신할 때 구체적인 것 말고 추상적인 것에 의존해라
• 그럼 코드가 변경되도 클라이언트 코드를 변경할 경우는 적다.

정리: 소프트웨어 품질

• 소프트웨어 품질의 시작은 개발자의 실수를 줄이는 환경 구축
• 모두가 이해하기 쉬운 코드를 작성할 것
• 디커플링 고려 시점
  • 협업 환경에서 잦은 변경으로 서로 일 못하는 상황이 생길 때
  • SOLID가 도움됨
• 필요하면 사용한다!
  • 굳이 필요없는 걸 굳이 하는 건 민폐
  • 새롭고 대단해보이면 의심해보자.

Reference

• Pocu Academy
• 29. SOLID Principle Aspect 01