refactoring #5 Simplifying Method Calls

아래 내용들은 바꿀 경우, super/sub class 에도 해당 되는지도 체크 해야한다

• method  이름은 간결하되, 내용을 제대로 표현하게. 
• method  에  parameter 추가는 좋으나, parameter 는 늘 추가하는건 쉽고, 삭제하는건 어려우며, 대개 param 사이즈가 엄청 늘어나게 되며 이경우 다른 refactoring 이 필요하다
• 사용되지 않는 parameter 는 삭제한다  
• 조회하는  query 와 수정을 가하는 modifier 는 따로 다른 method   로 분리되어야 한다. 
• 비슷한 method 인데 parameter 만 다른 경우, 하나로 합치고 parameter 로 분기할수 있는데, 자칫하다간 매우 길고 복잡한 하나의 method 로 합쳐질 수 있어 이 경우는 지양해야한다
• 위와 반대로, 하나의 method  가 길고 복잡하고 불필요하게 parameter 가 많은 경우, 두개의 method  로 나누고, parameter 도 필요에 따라 쪼갠다.
• parameter 여러개가 한 object 에서 나올 경우, object 를 그냥 넘겨도 된다. 하지만 int, String 같은 거였다가 object 로 바꿀 경우그럴 경우, 그 object 만이 method 에 쓰일 수 있다. 
• method 안에서 해결 될 수 있는 계산이면, method 안에서 처리 한다. 밖에서 해서 parameter 로 넘길 필요 없이
• parameter  들이 많고, 자주 method 에서 쓰이면 parameter object 로 하나의 class 로 묶고, 관련된 method 들도 거기로 옮겨버리면 깔끔해질 수 있다
• 생성자에서 변수 할당 이외에 복잡한 작업을 할 경우, factory method  로 대체한다.
• -1  같은 에러코드를 리턴하는 대신 exception 을 던진다.  0, -1 같은 코드가 아니므로 if-else 같은것에서 벗어나고,  error handling 하는 logic 을 따로 둠으로서 정상 시나리오로부터 분리할 수 있다. 
• 하지만 exception  은 unexpected, real error  를 위한 경우여야 하며,   사전 체크나 assert 등으로 확인할 수 있는건 미리 확인한다. 그리고 conditionla check 가 exception  catch보다 뭘 하고자 하는건지 더 명확하다.