[리팩토링] 악취 19 : 상속 (2)

✍️ 악취 19 : 상속 객체지향에서 상속은 코드 재사용과 기능 확장이라는 장점이 있지만 상속이 적절하지 않은 케이도 분명 있다. 서브 클래스는 슈퍼 클래스의 모든 기능을 지원해야 한다.(List를 상속받는 Stack이 적절한가?) 서브 클래스는 슈퍼 클래스가 가진 기능적 규약을 위반해선 안 된다. (리스코프 치환 원칙) 서브 클래스는 슈퍼 클래스의 변경에 취약한 다르게 말하면 둘의 결합도가 매우 높다. 무엇보다 다중 상속이 불가능하다. 상속은 매우 유용한 기능이지만 적절하지 못한 구조라고 판단하면 위임의 형태로 변경하는 것이 유용할 때가 있다. 여기 상속 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다. 1. "슈퍼 클래스를 위임으로 변경하기" 2. "서브 클래스를 위임으로 변경하기" 본 포스팅에서..

• format_list_bulleted 리팩토링
• · 2023. 2. 10.
• textsms

[리팩토링] 악취 19 : 상속 (1)

✍️ 악취 19 : 상속 객체지향에서 상속은 코드 재사용과 기능 확장이라는 장점이 있지만 상속이 적절하지 않은 케이도 분명 있다. 서브 클래스는 슈퍼 클래스의 모든 기능을 지원해야 한다.(List를 상속받는 Stack이 적절한가?) 서브 클래스는 슈퍼 클래스가 가진 기능적 규약을 위반해선 안 된다. (리스코프 치환 원칙) 서브 클래스는 슈퍼 클래스의 변경에 취약한 다르게 말하면 둘의 결합도가 매우 높다. 무엇보다 다중 상속이 불가능하다. 상속은 매우 유용한 기능이지만 적절하지 못한 구조라고 판단하면 위임의 형태로 변경하는 것이 유용할 때가 있다. 여기 상속 악취를 해결하기 위한 두 가지 리팩토링 기법이 있다. 1. "슈퍼 클래스를 위임으로 변경하기" 2. "서브 클래스를 위임으로 변경하기" 본 포스팅에서..

• format_list_bulleted 리팩토링
• · 2023. 2. 9.
• textsms

[리팩토링] 악취 18 : 중재자

✍️ 악취 18 : 중재자 메서드 호출을 위해 중간에 거쳐가는 존재를 말 그대로 중재자라고 한다. 구조에 따라서 중재자가 필요할 수도 불필요할 수도 있다. 다만 과도한 위임이 발생해서 메서드 호출마다 항상 중재자를 거쳐가야 한다면 중재자를 제거하는 방향으로 리팩토링할 수 있다. 여기 중재자 악취를 해결하기 위한 리팩토링 기법이 있다. 1. "중재자 제거하기" 중재자를 거치지 않고 클라이언트가 직접 객체를 사용하기 🍊 중재자 제거하기 '중재자 제거하기'는 캡슐화를 제거하고 메시지 체인을 사용한단 의미에서 '위임 숨기기'와 반대된다. 오히려 위임을 드러내는 리팩토링이다. * 개인적으로 메시지 체인보단 캡슐화로 필요한 정보만 제공하는것이 더 객체지향스럽다고 생각한다. 실제로도 대부분의 업무에선 캡슐화를 하는 ..

• format_list_bulleted 리팩토링
• · 2023. 2. 8.
• textsms

[리팩토링] 악취 17 : 메시지 체인

✍️ 악취 17 : 메시지 체인 객체에 메시지를 전달해서 기능을 수행한단 의미에서 '메시지란 메서드 호출'을 의미한다. 즉, 메시지 체인이란 연속된 메서드 호출을 의미한다. // 메시지 체인 person.getInfo().getAddress(); 메시지 체인이 리팩토링의 대상이 되는 이유는 클라이언트가 메서드 호출을 위해 너무 많은 것을 알아야 한다는 것이다. 가령 클라이언트는 Person에 Info 필드가 있고, Info에 Address 필드가 존재함을 이해해야 하만 원하는 정보를 얻을 수 있기 때문이다. 심지어 체인 구조가 변경되면 모든 클라언트의 코드가 변경된다는 단점도 존재한다. 여기 메시지 체인을 해결하기 위한 두 가지 리팩토링 기법이 있다. 1. "위임 숨기기" 메시지 체인을 캡슐화하기 2. ..

• format_list_bulleted 리팩토링
• · 2023. 2. 7.
• textsms

[리팩토링] 악취 16 : 임시 필드 *

✍️ 악취 16 : 임시 필드 클래스의 필드가 특정 상황에만 값을 갖고 그 외의 상황에는 null 또는 기본 값 혹은 임의의 값을 가질 때 이를 '임시 필드'라고 한다. 만약 클래스가 일반 필드와 임시 필드를 동시에 갖는다면 해당 클래스와 관련된 코드를 이해하기 어려워진다. 가령 임시 필드가 언제부터 제대로 된 값을 갖는지, 임시 값의 유무에 따른 동작이 어떻게 달라지는지 이해하는 건 결코 쉬운 일이 아니다. 여기 임시 필드를 세 가지 리팩토링 기법이 있다. 1. "클래스 추출하기" 임시 필드를 다루는 전용 클래스를 생성하기 2. "함수 옮기기" 기존에 임시 필드를 사용하는 메서드를 전용 클래스의 메서드로 옮기기 3. "특이 케이스 추출하기" 특정한 경우에 해당하는 클래스 만들기 본 포스팅에서 관심 있게..

• format_list_bulleted 리팩토링
• · 2023. 2. 6.
• textsms

[리팩토링] 악취 15 : 추측성 일반화

✍️ 악취 15 : 추측성 일반화 지금 당장 불필요함에도 나중에 필요할 것 같다는 추측으로 코드를 일반화 시켜 작성했지만 결국엔 사용되지 않는 상황이 발생한다. 모든 경우가 그렇진 않지만 특정 기능을 구현한 코드보다 일반화시킨 코드가 더 복잡하고 이해하기 어려운 경우가 많다. 그렇기에 일반화된 코드가 범용적으로 사용하지 않는다면, 앞으로도 그럴 계획이 없다면 리팩토링을 적용해볼만 하다. 여기 추측성 일반화를 위한 네 가지 리팩토링 기법이 있다. 1. "계층 합치기", 추상 클래스를 만들었지만 유효하지 않다면 2. "함수 인라인, 클래스 인라인", 불필요한 위임이 있다면 3. "함수 선언 변경하기", 재사용을 고려해 추가했지만 사용하지 않는 매개변수가 존재한다면 4. "죽은 코드 제거하기", 실행되지 않는..

• format_list_bulleted 리팩토링
• · 2023. 2. 4.
• textsms