[리팩토링] 악취 20 : 내부자 거래

✍️ 악취 20 : 내부자 거래 어떤 모듈이 다른 모듈의 정보를 지나치게 많이 알고 있다면 혹은 모듈이 지나치게 많은 것을 공개하고 있다면 강한 결합도가 발생할 수 있다. 이 중에서도 다른 모듈의 정보를 지나치게 많이 알고 있는 상황을 '내부자 거래'라고 한다. 다른 모듈의 정보를 지나치게 많이 요구한다면 필드나 메서드의 위치가 적절한지 생각해 보고 '함수 옮기기' 혹은 '메서드 옮기기' 리팩토링을 적용할 수 있다. 다른 여러 모듈에서도 동일한 현상이 발생한다면 자주 요구되는 필드와 메서드 혹은 클래스를 '별도의 모듈로 분리' 할 수 있다. 동시에 정보를 최대한 감추기 위해 '위임 숨기기' 도 적용할 수 있다. 여기 내부자 거래 악취를 해결하기 위한 세 가지 리팩토링 기법이 있다. 1. "함수/메서드 옮..

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

[리팩토링] 악취 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