객체지향 생활체조 원칙이 정량적인 기준을 제공해서 좋은 것 같지만, 극단적인 감이 있으니 강의에서 소개하는 규칙정도만 체득을 해야겠다
[tdd 연습시 주의]
- 큰 줄기 부터 세부 순서로(public 부터 private을 점진적으로 만들어감)
- 테스트 코드에 로직구현 금지
- 무조건 모든 경우의 수를 테스트하는 것이 아닌 유의미한 값을 테스트해야함. ex) 임계값, 경계값
- 최소 테스트를 통해 가장 효율적인 테스트를 하는 연습이 필요
- 이상적인 코드량은 테스트코드 : 프로덕션 코드 = 1 : 1
- 테스트 코드도 리팩토링이 필요하다
- 테스트 코드 리팩토링은 대부분 중복제거
- given, when, then은 오히려 가독성이 떨어질 수 있음. 코드량 자체를 줄일 때 세 개의 경계가 애매해져서 오히려 힘들 수 있음.
[객체 설계와 관련된 조언]
- OOP 개념(SOLID 등등)이 실제 코드에 적용하기에는 모호함이 있음(정성적)
- 정량적인 기준(객체지향 생활체조 원칙)으로 일단 시작하면 해당 이론에 대한 이해가 커져가고 센스가 생길 수 있음.
- 객체 설계가 어렵다보니 layered architecture만 사용하게 됨.
[객체지향 생활체조 규칙 3: 모든 원시값과 문자열을 포장한다.]
- 추상화레벨을 높이는 방식임
- 하다보면 관련로직이 하나로 묶이게 되고 이러한 클래스들이 생기다보면 유사성이 발견됨. 유사성이 발견되는 클래스는 다시 하나로 합칠 수 있게 되면서 리팩터링이 진행되는 것임.
- 응집도 면에서 가장 좋은 객체란 모든 메서드가 인스턴스 변수를 사용하고 있는 객체임.
- 단일 책임을 갖는 객체는 테스트하기도 편함
- 이러한 객체가 많아지고 좋은 OOP 설계가 된 구조에서는 단순 위임만 하는 객체가 많아짐. 이상한 게 아님. depth가 많이 깊어지는 것 같은 경우 객체간 의존관계(커플링)가 올바른지 확인할 것. 또는 상위 객체가 너무 많은 책임을 지고 있을 가능성이 있음. 이때에는 불필요한 인스턴스 변수를 갖고 있지는 않은지 확인할 것.
[객체지향 생활체조 규칙 8: 일급콜렉션을 쓴다.]
- 멤버변수를 하나만 가지는 콜렉션
- 객체리스트에 대한 모든 로직이 이 곳에 모일 수 있게된다.
ex) Lotto 넘버에 대한 카운트 제한 밸리데이션 로직 등 - 단 일급컬렉션 내에 일급컬렉션이 멤버변수로 들어가지 않도록 주의
[객체지향 생활체조 규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다]
- 멤버변수가 많다는 것은 응집도가 떨어진다는 것.
- 중복된 값 또는 불필요한 멤버변수 삭제
- 예를 들어 하나의 멤버변수 클래스로 얻을 수 있는 값을 따로 뺐다거나(Car클래스가 멤버변수인데 CarName을 따로 멤버변수로 갖는 것) 이럴 경우 오히려 데이터 싱크 맞추느라 유지보수에 공수가 더 든다. (like DB에서 역정규화)
- 관련있는 인스턴스 변수는 클래스로 묶기
[기타 팁]
- 타입이 다른 생성자를 여러개 제공하는 것은 추천. 타입을 한정적으로 제공할 경우 객체 밖에서 변환하는 과정이 반복될 가능성이 크기때문.
- private methods를 테스트하고자 할 경우
- default 접근제어자 활용
- reflection 도구 활용
- class 분리 고려 -> 추천하는 방법
- Enum도 클래스라는 점 기억하기! 한 번 초기화된 후 절대 바뀌지 않는 인스턴스 변수를 가지는 것 뿐임. (JVM상에서 singleton을 보장)
Junior Web Developer 😊