우테코 첫 강의를 들었다. 간단히 들은 내용을 보관한다 근데 나만 보려고 쓴거라 남이 읽으면 좀 이상할듯;;
Stream vs for-loop
stream 은 객체지향을 조금 떨어트리는 경향이 있어서 좀 더 객체지향을 학습하고 사용하길 바란다.
따라하기 방식은 의미가 없다. 생각하는 훈련이 필요하다. 동영상은 출퇴근 길에 그냥 봐라
무엇을 해야 할지 생각해두면 된다. 그리고 동영상 없이 혼자 해봐라
TDD에 앞서 요구사항 분석
완벽한 todo 리스트를 만들겠다고 생각하기 보다 요구사항을 분석하라 test case 가 만들어진다.
살아있는 todo list
•
todo list 를 작성할 때는 method, 자료구조 등은 고민하지마라
•
class 설계와 todo list 를 동시에 하지마라
도메인 객체 설계
•
요구사항 분석을 통해 대략적인 설계 - 객체 추출
◦
객체 지향 수준을 높히면 더 설계가 잘된다.
◦
잘 안되도 걱정하지 마라 test 가 있고, refactoring 이 있다.
◦
그러니 완벽한 설계를 추구하지 마라
•
리팩토링이 안된다면 코드를 날리고 다시 클린코드를 구현하라
•
UI, DB 등과 의존관계를 가지지 않는 핵심 도메인 영역을 집중 설계하라
View, Controller 는 나중에 고민하라
•
중요한건 domain 이다.
•
view, controller 는 test 구현이 어려운 영역이다.
•
domain 영역 만이라도 TDD 로 구현하는 것이 중요하다
◦
객체지향이 집중 되는 곳도 domain 이다.
•
도메인 설계는 다양한 방법이 있다.
•
테스트 하기 어려운 부분과 테스트하기 쉬운 부분을 분리하라
•
Random 같은 경우는 interface 로 분리할 필요가 있다.
◦
random 으로 나오는 값을 Mock 객체로 만들어 바꿔치기 하는 방법도 있다.
◦
JDK 에서 제공해주는 것은 어느정도 믿고 써도 괜찮다.
◦
random 이 random 하게 나오는지는 굳이 검증할 필요는 없다.
•
random, 날짜 이런게 test 가 어렵다.
•
TDD로 도전
◦
자동차 이름 split
else를 쓰지 못하게 하는 이유
•
if 에서 return 을 하는것이 좋다. early return
•
코드가 깔끔해지고 indent 를 없앨 수 있다.
테스트하기 어려운 부분을 찾아 가능한 구조로 개선
•
자동차 이름 유무 (DB - 여기서는 random)
•
우승자 이름 출력하기 (UI)
slide
테스트 하기 어려운 코드는 Object graph 의 상위 구조로 올린다.
이거를 잘해야 TDD 를 잘할 수 있다. 이 역량을 길러야 한다.
상위 object 로 빼라
RacingGame 이 의존관계를 갖게 한다.
변경의 대상이 많으면 좋은 refactoring 이 아닐 수 있으니, (overloading 을 사용하는 것도 방법이다.)
method signature를 받는것은 너무 복잡도가 증가한다
이런 방식으로 legacy 를 refactoring 한다
그런데 이 방법은 설계에 한계가 있을때 정말 어쩔수 없이 사용하는것이다.
이런 상황에서 interface 를 고민해야 한다.
copy 해서 refactoring 해본다.
핵심은 compile error 를 최소화 하면서 리팩토링 하는 것이다. (Overriding, Overloading 을 사용해 refactoring 을 수행한다.)
안전한 리팩토링을 위해 중간 과도기적인 선택을 해야 한다. (기존, overloading 코드 공존)
장난감 프로젝트에서 극단적인 over-engineering 을 해야한다. 이건 연습이니까!!
이렇게 시도해봐야 현업에서도 어디가 over-engineering 인지 구분할 수 있다.
원시값을 객체로
•
변수명이 class 이름이 되는 경우가 많다
이렇게 getValue() 를 사용하기 보단 equalsAndHashcode 를 구현하여 객체로 비교하라
객체의 생성자에서 validation 체크를 한다면 원시값 객체는 유효한 값만 포함하게 된다.
객체에게 메세지를 보내라
객체에 메세지 보내는 훈련, 그 메세지를 찾는것을 훈련해야 한다.
객체를 많이 만들면 성능이 떨어진다. 하지만, 그 차이는 굉장히 미묘하다.
성능 이슈는 DB call, network call 하는 부분이 더 크다. 이 부분에 대한 튜닝이 필요하지 객체에 대한 고민을 하는게 아니다. 이런 문제는 진짜 생겼을때 고민해라.
이럴땐 instance caching 을 하는 방법도 있다. Integer.caching
로또에도 캐싱이 필요한 곳이 있다.
1급 collection 을 만들어라
우승자 구하기: n대 자동차
테스트를 위한 method 를 추가하는 것은 문제가 있다. 하지만 생성자는 많으면 많을수록 좋다
생성자 parameter 가 final 인 이유는 그 변수에 재할당을 못하게 만드는 것이다.
collection 객체 하나를 wrapping 하는 객체를 1급 collection 이라 한다.
input 과 output 이 명확하다면 test 가 지켜주기 때문에 로직 구현에 너무 많은 시간을 쏟지마라
값을 반환하는 method 는 명사로 지어라, 동사로 시작하는 것은 이상하다
getMaxPosition 은 그냥 값을 날것으로 가져오는 것이지만, maxPosition() 은 무언가 해서 반환한다는 느낌이다.
class 이름은 무엇인지로 이름을 지어라, 무엇을 하는지로 짓는게 아니다.
setter < 생성자
