6월 6일부터 넥스트 스탭의 TDD, 클린 코드 with Kotlin 6기 수업에 참여하게 되어 1주차 회고를 작성합니다.
코틀린에 대해서
코틀린에 대해서 자바와의 차이점에 대해 학습했으며, 코틀린의 기본 문법에 대해서 알아보는 시간을 가졌습니다.
아토믹 코틀린을 읽는 중이였기에 이미 알던 내용이였지만 한번 더 학습할 수 있는 기회가 되었습니다.
2단계 - 문자열 계산기
문자열 계산기를 구현하는 미션이였습니다.
간단해보였지만, 강사님께서 객체 지향적으로 설계 해보는 것을 고려해보라고 말씀하셨기 때문에 생각보다 생각할 요소가 많았습니다.
그리고 메소드가 가능한 많은 역할을 하지 않는게 좋다라고 하셔서 문자열 식에 대한 클래스를 새로 두어 검증과 분리를 하도록 했습니다.
구현하면서 난관이였던 부분은, 객체 지향적인 설계는 무엇일까에 대한 생각이 드는 것이였습니다.
제가 생각했던 객체 지향 설계는 스프링을 학습할때 외웠던 SOLID 원칙이였는데, 각 원칙을 제가 어떻게 생각하고 적용했는지에 대해 간단히 공유하려고 합니다.
Calculator 클래스는 계산기 클래스이고, Formula 클래스는 입력 문자열을 분리해서 문자열 리스트를 프로퍼티로 가지고 있는 클래스입니다.
SRP - 단일 책임 원칙
Calculator 클래스 외에 Formula 클래스를 둔 이유입니다.
Calculator 클래스는 주어진 식을 계산한다. 라는 역할과 Formula 클래스는 입력 문자열을 검증하고 분해하는 역할로 나누어야겠다 라는 생각을 했습니다.
OCP - 개방-폐쇄 원칙
가장 막막했던 부분인데, 개인적으로 생각하기에는 계산기 클래스가 확장될 때에는 연산이 추가되는 정도라고 생각합니다. 그래서 저는 연산자에 대한 것을 맵으로 관리하고, 확장시에는 연산자만 추가하면 되기 때문에 지키지않았나? 라는 생각이 들었습니다.
LSP - 리스코프 치환 원칙
이것은 사실 지키지 못했습니다. 상속을 이용하는 경우에 지킬 수 있다고 생각하는데, Formula와 Calculator를 클래스로 사용하는 상황에서는 지킬 수 있는 방법이 떠오르지 않았습니다.
ISP - 인터페이스 분리 원칙
마찬가지로, 현재 Calculator와 Formula 클래스는 인터페이스를 사용하지 않고 있습니다.
그렇기 떄문에 지킬수 있는 방법이 잘 떠오르지 않았습니다.
DIP - 의존성 역전 원칙
마찬가지로 계산기 클래스가 식이라는 클래스를 직접적으로 의존하고 있기 때문에 이는 식 클래스가 입력에 대한 유효성 검사와 분해라는 책임을 가지고 있기 떄문에 합리적이지 않나..? 라는 생각을 했습니다.
더 복잡한 상황에서는 지키지 못했던 원칙을 지키도록 구성해야겠다는 생각이 들었고, 지난 프로젝트를 하면서도 이렇게까지 객체 지향 설계에 대해 고민했던 적이 없었기 때문에 이번 기회에 제대로 돌아볼 수 있는 미션이였습니다.