들어가기 전 이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 리팩토링 14. (Replace Parameter With Query) 함수의 매개변수 목록은 함수의 다양성을 대변하며, 매개변수가 적을수록 이해하기 쉽다. 한 매개변수를 통해 다른 매개변수를 알아낼 수 있다면 '중복 매개변수'라 생각할 수 있다. 매개변수에 값을 전달하는 것은 '함수를 호출하는 쪽'의 책임이다. 너무 많은 매개변수를 전달해야 한다면, 클라이언트에서 너무 많은 책임을 가지고 있음을 의미한다. 클라이언트가 사용하기도 어렵다. 가능하면 함수를 호출하는 쪽의 책임을 줄이고, 함수 내부에서 책임지도록 노력한다. '임시 변수를 질의 함수로 바꾸기'와 '함수 선언 변경하기'를 통해 이 리팩토링을 적용한다. 매개변수를 줄이면서 ..
들어가기 전 이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 냄새 4. 긴 매개변수 목록 (Long Parameter List) 어떤 함수에 매개변수가 많을수록 함수의 역할을 이해하기 어려워진다. 과연 그 함수는 한 가지 일을 하고 있는게 맞는가? 불필요한 매개변수는 없는가? 하나의 레코드로 뭉칠 수 있는 매개변수 목록은 없는가? 매개변수를 줄일 수 있는 방법 어떤 매개변수를 다른 매개변수를 통해 알아낼 수 있다면, '매개변수를 질의 함수로 바꾸기'를 사용할 수 있다. 기존 자료구조에서 세부적인 데이터를 가져와서 여러 매개변수로 넘기는 대신, '객체 통째로 넘기기'를 사용할 수 있다. 일부 매개변수들이 대부분 같이 넘겨진다면, '매개변수 객체 만들기'를 적용할 수 있다. 매개변수가 플래그로 ..
들어가기 전 이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 리팩토링 13. 조건문을 다형성으로 바꾸기(Replace Conditional with Polymorphism) 여러 타입에 따라 각기 다른 로직으로 처리해야 하는 경우에 다형성을 적용해서 조건문을 보다 명확하게 분리할 수 있다. (예, 책, 음악, 음식 등...) 반복되는 switch문을 각기 다른 클래스를 만들어 제거 할 수 있다. 공통으로 사용되는 로직은 상위 클래스에 두고 달라지는 부분만 하위 클래스에 둠으로써, 달라지는 부분만 강조할 수 있다. 모든 조건문을 다형성으로 바꿔야 하는 것은 아니다. Switch 문이나 If문은 일반적으로 조건이 다를 때, 각기 다른 액션을 취하도록 하는 문법이다. 조건문을 다형성으로 바꾸는 경..
들어가기 전 이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 리팩토링 12. 반복문 쪼개기 (Split Loop) 하나의 반복문 내에서 여러 작업을 동시에 처리하는 코드를 쉽게 찾아볼 수 있음. 이런 코드는 효율적이지만, 읽기 어렵다. 해당 반복문을 수정할 때 여러 작업을 모두 고려하며 코딩을 해야하기 때문이다. 반복문을 여러 개로 쪼개고, 각 반복문에서 각 작업을 하도록 하면 유지보수가 쉬워진다. 반복문 쪼개기는 성능 문제를 야기할 수 있지만, '리팩토링'은 '성능 최적화'와 별개의 작업이다. 리팩토링을 마친 이후에 병목 지점인 경우 성능 최적화를 시도해 볼 수 있다. 일반적으로 하나의 반복문 안에서 여러 작업을 동시에 진행하는 경우가 많다. 어차피 루프를 돌고 있으니, 똑같은 루프를 여러..
들어가기 전 이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 리팩토링 11. 조건문 분해하기(Decompose Conditional) 여러 조건에 따라 달라지는 코드를 작성하다보면 종종 긴 함수가 만들어 지는 것을 볼 수 있음. If문의 '조건'과 If문의 '액션' 모두 '의도'를 표현해야 한다. 기술적으로는 '함수 추출하기'와 동일한 리팩토링이다. 하지만 함수로 추출해서 If문의 각 부분이 '의미'를 잘 전달할 수 있는데 초점을 맞춘다. 조건문은 어느 순간 아주 복잡해 질 수도 있다. 그렇다면 조건문은 어떤 경우에 많이 복잡해 질 것인가? 조건 자체가 복잡해 질 수 있음. 각 조건을 만족했을 때, 해야할 일 자체가 길어질 수도 있다. 조건문이 세부 구현 사항과 강하게 결합하게 되면, 코드를..