2주차 회고 - 발전하기

1. 개발 목표

1주차에서 고민했고, 2주차에서 적용해보고 싶었던 것들이 있었다. 그리고 더 공부해 보고 싶었던 것들이 있었다.

• 검증 부분을 도메인과 합쳐 구현해 보자

1주차는 검증 부분을 도메인과 분리하여 개발했었다. 패키지를 분리하였고, 검증 클래스를 각각 만들어 유틸리티 클래스처럼 구현하였다. 클래스 간 결합도가 높아지고 객체지향적인 프로그래밍이 아니라는 판단에 이 부분을 바꾸어 보았다.

2주차는 도메인에 검증부분을 녹여냈다. 도메인 객체와 서비스에 검증 기능을 구현했다. 캡슐화 되어 응집도가 높은 코드가 되었다. 또한 입력 검증을 입력 뷰에서 처리하지 않고 서비스와 도메인에서 나눠 처리해주니 입력 뷰와 다른 클래스들 간의 결합도가 낮아져서 좋은 코드가 되었다.

• dto는 데이터 전송에만 사용하자

dto는 계층 아키텍처에서 계층 간 데이터 교환을 위해 사용하는 객체이다. 컨트롤러에서 서비스와 출력 뷰를 위해서 dto를 사용했었다. 이번에 사용했던 dto는 데이터의 형태만 정의되어 있었고 데이터 교환 기능만 해주었다. 다른 기능들은 도메인 객체들이 해주었다. 하지만 이 dto에 기능을 조금 더 추가하여 도메인 객체로 만들어 사용해도 될 것 같다는 생각이 들었다.

• 정규식을 더 공부해보고 적용해보자

정규식 공부는 과제에서 정규식을 사용해야하는 경우가 주어졌을 경우 하고 싶었다. 2주차 과제에는 정규식을 쓸 부분이 없다고 판단하여 다음으로 미루었다.

• 유틸리티 클래스와 객체지향의 관계에 대해 공부해보자

https://blueconecell.tistory.com/147

9일차 - 유틸리티 클래스란

 

9일차 유틸리티 클래스에 대해 객체지향클래스와 비교하며 공부해 봤었다.

유틸리티 클래스는 절차지향적 프로그래밍에 사용하는 클래스로 static으로 선언되어 인스턴스 생성 없이 사용할 수 있다. 하지만 유지보수에 취약한 점이 있고, 객체지향적이지 않아 도메인 상관없이 어디서든 사용할 공통적인 기능에 대해서만 유틸리티 클래스로 선언해주는 것이 좋다.

• 테스트코드 작성

예외 처리에 대해 중점적으로 테스트 코드를 만들었다. 테스트 코드를 만들면서 잘못 구현된 것들을 알게 되는 점도 있어서 좋았다.

쳬계적인 테스트 코드를 아직 만들 줄 몰라서 정상적인 경우와 비정상적인 경우에 대해서만 나누어 테스트 했었다. 나중에 단위 테스트에 대하여 공부하여 단위 테스트 + 통합 테스트로 코드를 짜봐야 겠다.