프로젝트를 진행하는 도중 다양한 상황들과 개발을 부딪히게 되었다.
그러한 과정에서 겪은 우여곡절과 현재 공부를 하면서 내가 잘못된 부분이 무엇인지에 대해서 정리하는 글이다.
단일 책임 원칙 (Single-responsibility principle)
사실 나는 이론에 강한 사람이 아니다... 실제 하려는 것들은 이론과 다르다고 굳게 믿는 사람이고 이론은 결국 허울좋은 이상일뿐이라고 생각하는 사람이다...
하지만 개발에서는 오만한 생각인거 같다 최소한 OOP에서 만큼은 더더욱 그런거 같다...
학생 때 공부했던 SOLID에 대해서 그렇게 중요하게 생각하지 않았다!
그 이유는 간단하다
SOLID 원칙을 안지켜도 개발은 된다!
그렇게 알고 있었고 그게 맞기도 하다.. 하지만, 유지보수성 그리고 확장성 있는 프로그래밍 설계와 함께 OOP라는 컨셉에 맞게 개발하기 위해서는 되도록 지키는게 좋다
단일 책임 원칙을 안지킨 그 전의 설계
게시판이 있다.
게시판에는 다양한 카테고리가 있다.
카테고리는 그 성격이 다양하기에 데이터 베이스에 지원하는 것과 미지원하는 것들이 다르다.
나는 설계의 중점을 '데이터베이스'에 맞추어서 진행했다.
테이블을 많이 만들어 읽기에 성능 중심을 줄 것인지 아니면 적게 만들어 쓰기에 중심을 줄 것인지 선택을 하였다.
나의 선택은 쓰기였다...
하나의 테이블에 모든 카테고리가 가질 수 있을만한 것들을 컬럼으로 생성하였다.
그렇게 되니 결국 DTO에 null이 들어와야하고, 아니면 null이 아니라면 DTO를 보고서는 무엇을 필요로 하는지 몰라 Response를 보고 판단을 해야하는 상황이 있다.
(아이러니 하게 ResponseDTO는 단일 책임 원칙을 지켰다)
어떻게 지킬까?
결국 JPA의 기능을 최대한으로 활용해야한다 데이터베이스는 상속이라는 것을 지원하지 않기 때문에 상당히 SRP에 대한 생각을 하지 않았는데 어노테이션 @Inheritance를 통해 이러한 부분을 지킬 수 있도록 하였다.
사실... 느낀점이기 때문에 코드에 대한 내용은 없고 결국 내가 느낀건 이런 것이다.
- 내가 이해한다고 단일책임원칙을 안지키면 안된다
- 사람의 기억력이 한계가 있어서 내가 이해해도 까먹는다.
- 확장성을 고려한다면 단일책임원칙을 지키는게 좋다.
- OOP는 상속이라는 특성이 있는데 왜 하나의 클래스에 모든 데이터를 말아버리려는 생각은 다시 해보면 좋다.
