SOLID 설계 정신에 대해 알아보자.
SOLID 정신으로 이룰 수 있는 것
- 소프트웨어 설계를 “유연하게” 할 수 있다.
- 유연한 소프트웨어 설계, 즉 추상적인 설계로 커플링을 제거할 수 있다.
- 다만, 추상적으로 될 수록 이해하기 어려워지는 측면이 있기 때문에 유지보수 측면에서 악영향을 줄 가능성도 있다.
도움이 될만한 곳
- 대규모 프로젝트
- 모든 프로젝트에 적용할 수 있다고 생각하지는 말자.
- 직접적/구체적인 것이 더 이해하기 쉽다.
- 규모가 커지면서 유연성이 필요해지는 시점에 도움이 될 것이다.
- 예전에는 외주 개발을 했기 때문에 더 유연성이 중요했다.
- 즉, 예전에는 SOLID가 더 말이 됐었다.
- 계약시 스펙에 따라 금액을 산정했었다.
- 요즘은 작은 요구사항, 잦은 변경사항 때문에 재사용성 높은 설계가 도움이 안될 수 있다.
단일 책임
Only do one thing, One reason to change
- 클래스의 존재 이유는 하나여야만 한다.
- 한 함수에서 너무 많은 일을 하지말라 > 확장
- 그런데 하나라는 의미가 정확히 무엇일까?
- 하나의 개념이 매우 주관적이다.
- 이는 결국 가독성과 관련된 이야기다.
- 사람이 한번에 쉽게 이해할 수 있는 정보의 크기에 대한 이야기다.
단일 책임 정신의 의의
- 이 코드를 보는 대부분의 사람이 이해할 수 있는 크기로 클래스를 만들자.
- 객관적으로 만들겠다고 메서드 개수 제한과 같은 규칙을 정하지 말자.
- 짧아도 안 읽히는 글이 있고, 길어도 잘 읽히는 글이 있다.
- 이건 사실 함께 일하는 팀에서 정해야하는 부분임
단일 책임 정신을 어겼음을 보여주는 지표
- 클래스 이름에
And가 들어간 경우 - 이건 메서드 이름에도 적용됨
개방-폐쇄
Open for extension, Closed for modification
- 클래스 내부 수정없이 동작을 확장할 수 있어야 한다.
- Switch, if 문을 사용해서 특정 객체를 수정하는 것은 어긋난 예
- 상속 + 다형성을 사용하자는 말
- 이걸 잘 적용하면 단일 책임 정신도 이룰 가능성이 높다.
극단적인 주장
- 한번 만든 클래스는 절대로 바꾸면 안됨
- 방향성 자체는 좋다.
- 하지만 바꿔야 하는 상황도 충분히 많다.
- 바꾸는게 유지보수에 더 좋을 수도
- breaking change (호환성 문제가 발생할 수 있는 수정사항)
- 모든 문제를 프로그래밍으로 풀지 말자.
- git과 같은 도구를 사용하면 예전에 사용했던 클래스 지워도 복구 가능함
리스코프 치환
- 자식 개체를 부모 개체로 대체하더라도 동작해야 한다.
- 즉, 부모가 할 수 있었던 일은 자식도 할 수 있어야 한다.
한계
- 매우 맞는 말이지만 어려울 수 있다.
- 모든 자식을 추상화한 것이 부모라 할 수 있다.
- 그런데, 자식을 추가하는 과정에서 부모의 동작을 바꿔야 하는 상황이 있을 수 있다.
- 즉, 추상화된 부모가 항상 맞을 수 없기 때문에 발생하는 문제다.
- 추상화는 구체적인 것들의 공통점을 모아서 만드는 것이다.
- 만약 구체적인 개체가 추가된다면, 이 모든 것의 공통점을 찾아 부모를 고쳐주어야 하는게 자명하다.
- 다만 이게 자주 일어나면 좋지는 않겠다.
인터페이스 분리
큰 인터페이스가 몇 개 있는 것보다는 작은 인터페이스가 많이 있는게 좋다.
- 여전히 이해할 수 있는 정보의 크기의 문제다.
- 작은 단위로 쪼갤 수 있으면 쪼개는게 보통 이해하기 쉽다.
- 역시 밸런스의 문제다.
의존 역전
- 개체끼지 통신할 때 구체적인 것 말고 추상적인 것에 의존해라
- 그럼 코드가 변경되도 클라이언트 코드를 변경할 경우는 적다.
정리: 소프트웨어 품질
- 소프트웨어 품질의 시작은 개발자의 실수를 줄이는 환경 구축
- 모두가 이해하기 쉬운 코드를 작성할 것
- 디커플링 고려 시점
- 협업 환경에서 잦은 변경으로 서로 일 못하는 상황이 생길 때
- SOLID가 도움됨
- 필요하면 사용한다!
- 굳이 필요없는 걸 굳이 하는 건 민폐
- 새롭고 대단해보이면 의심해보자.