10-24일 라이브 강의

린치핀 책 추천

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

레거시 코드 리팩터링

 

 

 

 

 

 

 

 

테스트하기 쉬운 코드와 어려운 코드가 상위노드에 있는 것.

 

해결 방법은 하위 노드로 비즈니스 로직을 이동 시키는 것.

테스트하기 어려운 코드만 상위노드에 둔다.

 

 

 

 

TDD 레거시 리팩토링시 마지막 가장 아래 하위 노드부터 시작하는 것ㅇ ㅣ좋다.

 

 

 

 

 

도메인 객체에 로직을 구현하면 얼마든지 TDD 구현이 가능하다.

+ 도메인 객체에 메세지를 보내는 식으로 수정하기.

 

 

레거시 코드 리팩토링과 로또 병행하기

 

 

 

 

 

객체생성에 대한 정보를 많이 가지고 있는 객체한테 위임하기

 

DeleteHistory를 question과 answer에 각각 위임해보는 방식

 

 

 

 

 

날짜데이터가 테스트하기 어려운 상황

 

isNotNull을 활용해보는 방식도 있음

 

 

 

 

 

 

 

 

 

 

 

 

Entity  객체와 도메인 객체의 차이

 

Entity : 

테이블과 1대1 매핑. DB에 저장하거나 자바객체로 변환하는 객체를 의미.

 

도메인 객체, 모델 객체

매핑관련 로직은 없는 순수 pojo객체.(Car, Lotto 클래스)

 

 

 

도메인을 DB 저장시 entity로 변환시켜줘야되서 분리하면 단점이 있음.

 

로직의 복잡도가 높지 않으면 하나로 통합 지향

나누면 개발 및 유지보수시 어려움

 

서비스레이어는 거의 테스트하지 않는다. 로직이 거의없으므로

 

1. 서비스레이어는 연결만 하고 도메인으로 로직 옮기고 TDD로 개발

2. 레거시코드 변경할 때, 리팩토링하고 도메인객체에 변경된 요구사항 반영하고 테스트

 

 

 

 

도메인 클래스내에 일급 컬렉션 만들어보기

 

 

 

 answer 클래스를 만들고 안으로 옮길 수 있는 로직을 이동시켜본다.

 

 

 

 

 

 

 

인스턴스 변수가 너무 많을때 하나의 클래스로 합쳐 보는 것 

 

 

 

 

 

둘중 더 나은 방법은?

2번을 하면 빼먹을 수도 있어서.

원칙은 메서드들을 작은 단위로 나누는 것이지만

외부에서 구현시 빼먹을 수 있음.

canDelete를 필수로 써야한다는 걸 학습해야 하는 불편함이 있음.

필수로 호출해야 되는 메서드들은 굳이 분리할 필요가 없지 않을까

 

 

 

 

 

2번의 경우 2가지의 책임을 delete가 가진다.

2번을 지양하라고 함.

delete메서드를 사용해서 객체의 상태를 바꿈. -> 뭔가를 반환할 필요는 없음.

toDeleteHistories는 뭔가를 반환하는 것.

 

 

 

 

out -in : 미리 클래스들 부터 구현

 

int -> out 방식으로 진행할때 TDD가 수월함.

가장 작은 객체가 무엇일지 찾는 것