(스터디) 파이브 라인스 오브 코드 - 5장 유사한 코드 융합하기

5장 유사한 코드 융합하기

이번 장에서 다룰 내용

• 유사 클래스 통합하기
• 조건부 산술로 구조 노출하기
• 간단한 UML 클래스 다이어그램 이해하기
• 전략 패턴의 도입(p5.4.2)으로 유사 코드 통합하기
• 구현체가 하나뿐인 인터페이스를 만들지 말 것(R5.4.3)으로 어지러움 정리하기

5.1 유사한 클래스 통합하기

• 리팩터링에서 "유사한 클래스 통합하기"란 비슷한 기능을 하는 여러 클래스들을 하나의 클래스로 합치는 작업을 말합니다. 이러한 리팩터링의 목적은 코드 중복을 줄이고 유지보수를 용이하게 하기 위함입니다. 유사한 클래스들이 서로 비슷한 메서드나 필드를 가지고 있다면, 이들을 통합하여 하나의 클래스로 만드는 것이 좋습니다.
• 이 과정은 다음과 같은 단계로 진행됩니다:

1. 공통 요소 식별: 먼저, 유사한 클래스들 사이에 공통적으로 존재하는 메서드와 필드를 식별합니다.
2. 슈퍼클래스 생성: 공통 요소들을 포함할 새로운 슈퍼클래스(부모 클래스)를 생성합니다.
3. 상속 구조 적용: 기존의 유사한 클래스들이 새로운 슈퍼클래스를 상속받도록 합니다. 이 때, 각 클래스의 특정 기능은 서브클래스(자식 클래스)에 남겨둡니다.
4. 중복 코드 제거: 서브클래스에서 중복되는 코드를 제거하고, 해당 기능을 슈퍼클래스에서 처리하도록 합니다.
5. 테스트 및 검증: 클래스 통합 후, 전체 시스템이 여전히 정상적으로 작동하는지 테스트합니다.

• 예를 들어, **Cat**과 Dog 라는 두 클래스가 있고, 두 클래스 모두 eat, sleep 같은 메서드를 가지고 있다면, **Animal**이라는 슈퍼클래스를 만들어 이 메서드들을 **Animal**로 옮길 수 있습니다. 이후 **Cat**과 **Dog**는 **Animal**을 상속받게 하여 중복을 제거합니다.
• 이러한 리팩터링은 코드의 중복을 줄이고, 유지보수를 용이하게 하며, 더 깔끔하고 이해하기 쉬운 구조를 만드는 데 도움이 됩니다.

메서드가 무조건 한번에 하나의 기능을 하는 것이 답이 아니라 상위 클래스에서 2개의 기능을 지원하는 것이 떄로는 지혜로운 방법이라는 거야??

네, 맞습니다. 메서드가 한 번에 하나의 기능만 수행하는 것이 항상 최선의 방법은 아닙니다. 때로는 상위 클래스에서 두 개 이상의 기능을 지원하는 것이 더 효율적이고 지혜로운 방법일 수 있습니다. 이는 상황에 따라 달라질 수 있는데, 몇 가지 중요한 측면을 고려해야 합니다:

1. 코드 중복 감소: 상위 클래스에서 여러 기능을 제공함으로써 코드 중복을 줄일 수 있습니다. 비슷한 기능을 하는 여러 메서드가 여러 하위 클래스에 걸쳐 있다면, 이를 상위 클래스에 통합함으로써 중복을 제거하고 유지보수를 용이하게 할 수 있습니다.
2. 응집도와 결합도: 클래스의 응집도(하나의 클래스나 모듈이 특정 목적이나 역할에 얼마나 집중되어 있는지)를 높이고 결합도(다른 클래스나 모듈에 대한 의존도)를 낮추는 것이 좋습니다. 상위 클래스에서 여러 기능을 제공하는 것이 이 두 조건을 만족시킨다면, 그것은 바람직한 접근법일 수 있습니다.
3. 확장성과 유연성: 상위 클래스에서 다양한 기능을 제공하면 하위 클래스는 필요한 기능을 선택적으로 사용하거나 확장할 수 있습니다. 이로 인해 시스템의 확장성과 유연성이 향상될 수 있습니다.
4. 가독성과 유지보수: 하나의 클래스나 메서드가 너무 많은 기능을 담당하면 가독성과 유지보수가 어려워질 수 있습니다. 그러나 적절하게 기능을 분리하고 조직화한다면, 이 문제를 해결하면서도 효율적인 코드 구조를 유지할 수 있습니다.

최종적으로, 상위 클래스에서 여러 기능을 지원하는 결정은 프로젝트의 특정 요구사항, 코드의 구조, 팀의 작업 방식 등 다양한 요소를 고려하여 결정해야 합니다. 이상적인 설계는 상황에 따라 다를 수 있으므로, 각각의 상황에 맞는 최적의 해결책을 찾는 것이 중요합니다.

5.1.1 리팩터링 패턴:유사 클래스 통합

5.2 단순한 조건 통합하기

"리팩터링에서 단순한 조건 통합하기"는 코드 내에 중복되는 조건문을 하나로 합치는 리팩터링 기법입니다. 이 방법은 코드의 가독성을 높이고 유지보수를 쉽게 하기 위해 사용됩니다. 보통 다음과 같은 경우에 적용됩니다:

1. 중복된 조건문: 코드 내에서 같은 조건을 검사하는 여러 조건문이 있을 때, 이를 하나로 통합할 수 있습니다.
2. 유사한 조건문: 비슷한 조건을 검사하는데, 각각 다른 코드 블록을 사용하는 경우에도 통합할 수 있습니다.

리팩터링 과정은 다음과 같습니다:

1. 조건문 식별: 중복되거나 유사한 조건문을 식별합니다.
2. 조건 통합: 유사한 조건문을 하나의 조건문으로 통합합니다. 이 때, 논리 연산자(AND, OR 등)를 사용하여 조건들을 결합할 수 있습니다.
3. 코드 재배치: 통합된 조건문 내에서 실행되어야 할 코드를 적절히 재배치합니다.
4. 테스트 및 검증: 리팩터링 후, 코드가 여전히 올바르게 동작하는지 확인하기 위해 테스트를 수행합니다.

예를 들어, 아래와 같은 코드가 있다고 가정해 보겠습니다:

if (temperature > 30) {
    coolSystem();
}
if (humidity > 70) {
    coolSystem();
}

이 경우, 두 조건문은 모두 coolSystem() 함수를 호출합니다. 리팩터링을 통해 이를 하나의 조건문으로 통합할 수 있습니다:

if (temperature > 30 || humidity > 70) {
    coolSystem();
}

이렇게 하면 코드의 중복을 줄이고, 의도를 더 명확하게 표현할 수 있습니다. 리팩터링의 핵심은 코드의 기능을 유지하면서 가독성과 관리 용이성을 향상시키는 것입니다.

분명 다른 조건이지만 같의 목적이나 의미라면 통합을 고려하는 것도 좋아보이네

맞습니다. 다른 조건이더라도 같은 목적이나 의미를 가진다면, 이러한 조건들을 통합하는 것이 매우 유익할 수 있습니다. 이런 접근 방식은 여러 면에서 이점을 제공합니다:

1. 코드 간결성: 여러 조건문을 하나로 통합하면 코드가 더 간결해지고, 이해하기 쉬워집니다. 이는 특히 복잡한 로직이 많은 코드에서 유용합니다.
2. 유지보수 용이성: 중복된 로직을 줄이면, 나중에 코드를 수정할 때 변경해야 하는 부분이 줄어듭니다. 이는 유지보수를 훨씬 쉽게 만들어 줍니다.
3. 오류 감소: 비슷한 로직을 여러 곳에 중복하여 사용하면, 나중에 한 곳을 수정할 때 다른 곳을 놓치는 실수를 할 수 있습니다. 조건문을 통합하면 이런 실수의 가능성을 줄일 수 있습니다.
4. 성능 최적화: 경우에 따라서, 조건문을 통합함으로써 코드의 실행 효율성을 높일 수도 있습니다. 중복된 조건 검사가 줄어들기 때문입니다.

하지만, 항상 조건문을 통합하는 것이 최선은 아닙니다. 통합이 코드의 가독성을 해치거나, 각 조건의 의미가 명확하게 구분되어야 하는 경우에는 개별적으로 두는 것이 더 나을 수도 있습니다. 이러한 결정은 코드의 맥락과 유지보수의 용이성, 그리고 팀의 코딩 스타일과 가이드라인에 따라 달라질 수 있습니다.

5.2.1 리팩터링 패턴: if 문 결합

리팩터링에서 "if 문의 결합"은 비슷하거나 관련된 여러 조건문을 하나의 if 문으로 통합하는 패턴을 말합니다. 이러한 리팩터링은 코드의 가독성을 향상시키고 중복을 줄이는 데 도움이 됩니다. 주로 아래와 같은 상황에서 사용됩니다:

1. 비슷한 조건문: 서로 다른 if 문이지만, 비슷한 조건을 검사하는 경우.
2. 같은 결과를 수행하는 조건문: 여러 if 문이 같은 작업을 수행하는 경우.

이 패턴을 사용하는 과정은 다음과 같습니다:

1. 조건문 식별: 통합할 조건문들을 식별합니다.
2. 논리 연산자 사용: 논리 연산자(AND, OR 등)를 사용하여 여러 조건을 하나의 if 문에 결합합니다.
3. 코드 재조정: 결합된 if 문 내부의 코드를 적절히 조정합니다.
4. 테스트 및 검증: 리팩터링 후 코드가 여전히 올바르게 동작하는지 테스트를 통해 확인합니다.

예를 들어, 다음과 같은 코드가 있다고 가정해 보겠습니다:

if (temperature > 30) {
    activateCoolingSystem();
}
if (humidity > 50) {
    activateCoolingSystem();
}

이 경우, 온도와 습도 조건이 모두 충족될 때 냉각 시스템을 활성화하는 것이 목적일 수 있습니다. 이를 하나의 if 문으로 결합하면 다음과 같이 됩니다:

if (temperature > 30 && humidity > 50) {
    activateCoolingSystem();
}

이렇게 하면 코드가 더 간결해지고, 같은 작업을 하는 조건문이 중복되지 않게 됩니다. 하지만, 항상 모든 if 문을 결합하는 것이 최선은 아닙니다. 때로는 개별적으로 조건을 두어 코드의 명확성을 유지하는 것이 더 나을 수 있습니다. 따라서, 리팩터링은 코드의 전체적인 맥락과 목적을 고려하여 신중하게 진행해야 합니다.

5.3 복잡한 조건 통합하기

"리팩터링에서 복잡한 조건 통합하기"는 코드 내에서 복잡하거나 중첩된 여러 조건문을 단순화하고 통합하는 리팩터링 기법입니다. 이 기법은 주로 가독성을 향상시키고, 유지보수를 용이하게 하며, 오류 가능성을 줄이기 위해 사용됩니다. 복잡한 조건문의 통합은 다음과 같은 방법으로 진행될 수 있습니다:

1. 조건문 분석: 먼저, 코드 내의 복잡한 조건문을 분석합니다. 이는 중첩된 if 문, 여러 논리 연산자가 결합된 긴 조건문 등을 포함할 수 있습니다.
2. 중복 로직 식별: 중복되는 로직이나 비슷한 패턴을 가진 조건문을 식별합니다.
3. 조건문 추출 및 단순화: 중복되거나 복잡한 로직을 별도의 메서드나 함수로 추출하고, 이름을 지정하여 그 목적을 명확히 합니다. 예를 들어, isEligibleForDiscount()와 같은 방식으로 이름을 지정할 수 있습니다.
4. 복잡한 조건의 분할 및 통합: 복잡한 조건을 더 간단한 여러 조건으로 분할하고, 이를 논리적으로 재구성하여 통합합니다. 예를 들어, if (conditionA && conditionB || conditionC)와 같은 조건은 if (isValidCondition())의 형태로 추출하고 통합할 수 있습니다.
5. 테스트 및 검증: 리팩터링 후에는 반드시 코드가 여전히 정상적으로 동작하는지 테스트하여 검증해야 합니다.

이러한 리팩터링의 예로, 다음과 같은 복잡한 조건문이 있을 수 있습니다:

if ((user.isMember() && user.hasValidMembership()) || (user.isVIP() && user.hasValidCoupon())) {
    applyDiscount();
}

이 조건문을 리팩터링하여 더 명확하게 표현하면 다음과 같습니다:

if (user.isEligibleForDiscount()) {
    applyDiscount();
}

// 별도의 메서드 내에서 조건 로직을 처리
public boolean isEligibleForDiscount() {
    return (user.isMember() && user.hasValidMembership()) || (user.isVIP() && user.hasValidCoupon());
}

이렇게 하면 원래의 복잡한 조건문을 더 읽기 쉽고 관리하기 쉬운 형태로 바꿀 수 있습니다. 리팩터링은 코드의 기능을 변경하지 않으면서 코드의 구조를 개선하는 것이 핵심입니다.

복잡한 if문의 조건을 간단한 메소드의 명으로 선언해서 리턴하면 간단하게 의미를 전달 할 수 있구나

코드 줄 수가 늘어나는 것은 크게 중요한 것은 아니네

맞습니다, 복잡한 if문의 조건을 간단하고 의미 있는 메서드로 추출하는 것은 코드의 가독성과 관리 용이성을 크게 향상시킬 수 있습니다. 이 방법은 다음과 같은 장점들을 가지고 있습니다:

1. 의미 명확성: 복잡한 조건 로직을 의미가 명확한 메서드 이름으로 전환함으로써, 코드를 읽는 사람이 해당 조건문의 목적을 더 쉽게 이해할 수 있습니다. 예를 들어, isEligibleForDiscount()라는 이름은 해당 조건이 할인 자격 여부를 검사한다는 것을 명확히 표현합니다.
2. 중복 제거: 동일하거나 유사한 조건문이 여러 곳에 사용되는 경우, 이를 하나의 메서드로 추출하면 중복을 제거할 수 있습니다. 이는 코드의 유지보수를 쉽게 만들어 줍니다.
3. 테스트 용이성: 복잡한 조건문을 별도의 메서드로 분리하면, 해당 메서드에 대한 유닛 테스트를 작성하기가 더 쉬워집니다. 이는 코드의 신뢰성을 높이는 데 도움이 됩니다.
4. 리팩터링 용이성: 나중에 조건 로직을 변경해야 할 경우, 별도의 메서드로 분리되어 있으면 그 변경이 훨씬 쉬워집니다. 이는 한 곳에서만 변경하면 되기 때문입니다.

코드의 길이가 약간 늘어나더라도, 이러한 장점들은 코드의 전반적인 품질과 유지보수성을 향상시키는 데 큰 도움이 됩니다. 따라서, 이런 리팩터링 기법은 장기적인 관점에서 볼 때 코드의 질을 높이는 데 매우 중요합니다.

5.3.1 조건을 위한 산술 규칙 사용

"리팩터링에서 조건을 위한 산술 규칙 사용"은 코드 내의 조건문을 더 명확하고 간결하게 만들기 위해 산술 연산을 적절히 활용하는 리팩터링 기법입니다. 이 방법은 복잡한 조건문을 단순화하여 가독성을 높이고, 오류의 가능성을 줄이기 위해 사용됩니다.

산술 규칙을 사용하는 리팩터링은 주로 다음과 같은 상황에서 적용됩니다:

1. 중복된 조건 제거: 동일한 계산이나 비교를 여러 번 수행하는 조건문에서 산술 규칙을 사용하여 중복을 제거할 수 있습니다.
2. 조건문 단순화: 복잡한 조건문을 산술 연산을 통해 단순화하거나, 더 명확한 로직으로 변환하여 가독성을 향상시킵니다.
3. 성능 향상: 경우에 따라 산술 규칙을 적용함으로써 코드의 실행 효율을 높일 수 있습니다.

예를 들어, 다음과 같은 조건문이 있다고 가정해 보겠습니다:

if (score >= 50 && score <= 100) {
    // Do something
}

이 조건문은 score가 50과 100 사이에 있는지를 검사합니다. 이를 산술 규칙을 사용하여 다음과 같이 단순화할 수 있습니다:

int lowerLimit = 50;
int upperLimit = 100;

if (lowerLimit <= score && score <= upperLimit) {
    // Do something
}

이렇게 하면 코드의 가독성이 향상되고, 나중에 조건의 범위를 변경해야 할 때 수정하기 쉬워집니다. 또한, lowerLimit과 upperLimit 같은 명확한 변수 이름을 사용함으로써 코드의 의도를 더 명확하게 전달할 수 있습니다.

이러한 리팩터링은 간단해 보일 수 있지만, 복잡한 코드에서 조건 로직의 명확성을 크게 향상시키는 데 도움이 됩니다. 리팩터링의 목적은 코드의 기능을 변경하지 않으면서, 코드를 더 이해하기 쉽고 관리하기 쉬운 구조로 개선하는 것입니다.

5.3.2 규칙: 순수 조건 사용

맞습니다, "순수 조건 사용" 리팩터링은 조건 로직과 실행 로직을 명확히 분리하여, 각각의 목적을 더욱 명확하게 하는 리팩터링 방법입니다. 이 방식은 코드의 가독성을 향상시키고, 부수 효과로 인한 잠재적인 버그를 줄이며, 코드의 유지보수를 용이하게 합니다. 주요 원칙과 장점을 살펴보면 다음과 같습니다:

1. 조건과 실행의 분리: 조건문 내에서는 단순히 조건을 평가하는 역할만 수행하고, 실제 로직의 실행은 조건문 밖에서 이루어지도록 합니다. 이는 조건문의 목적을 순수하게 유지하는데 도움이 됩니다.
2. 부수 효과 제거: 조건문에서 변수의 상태를 변경하거나 외부 시스템과의 상호작용 같은 부수 효과를 발생시키지 않도록 함으로써, 코드의 예측 가능성과 신뢰성을 높입니다.
3. 가독성 향상: 조건문이 단순하고 명확해지면, 다른 개발자들이 코드를 이해하기 쉬워집니다. 이는 코드의 가독성을 크게 향상시킵니다.
4. 테스트 용이성: 순수한 조건문은 테스트하기 쉽습니다. 조건 로직과 실행 로직이 분리되어 있기 때문에, 각각을 독립적으로 테스트할 수 있습니다.
5. 유지보수성 증가: 조건 로직이 단순해지면, 나중에 변경이나 확장이 필요할 때 코드를 수정하기가 더 쉬워집니다.

이러한 리팩터링 방식은 코드의 품질을 높이고, 장기적인 관점에서 개발 프로젝트의 효율성을 증가시키는데 크게 기여합니다. "조건은 조건대로, 로직은 로직대로"라는 원칙을 통해, 코드를 더욱 명확하고 관리하기 쉬운 형태로 만들 수 있습니다.

5.3.3 조건 산술 적용

"리팩터링에서 조건 산술 적용"은 코드 내의 복잡한 조건문을 간결하고 명확한 산술 연산으로 대체하는 리팩터링 방법을 말합니다. 이 방식은 코드의 가독성을 높이고, 오류의 가능성을 줄이며, 전반적인 코드의 품질을 향상시키는 데 도움이 됩니다. 주로 아래와 같은 경우에 적용됩니다:

1. 복잡한 조건문 단순화: 여러 조건을 검사하는 복잡한 if 문을 보다 단순한 산술 연산으로 표현하여, 코드의 이해를 쉽게 합니다.
2. 가독성 향상: 산술 연산을 사용하여 조건을 표현함으로써, 코드의 의도를 더 명확하게 전달할 수 있습니다.
3. 유지보수 용이성: 산술 연산을 통해 표현된 조건문은 변경이나 확장이 필요할 때 수정하기가 더 쉽습니다.

예를 들어, 다음과 같은 조건문이 있다고 가정해 보겠습니다:

if ((score >= 60 && score < 70) || (score >= 70 && score < 80) || (score >= 80 && score < 90)) {
    // ...
}

이 조건문은 score가 60 이상 90 미만일 때를 검사합니다. 리팩터링을 통해 이를 산술 연산을 사용하여 다음과 같이 간단하게 만들 수 있습니다:

if (score >= 60 && score < 90) {
    // ...
}

이러한 리팩터링은 코드를 더 간결하게 만들 뿐만 아니라, 조건의 의도를 더 명확하게 전달합니다. 또한, 이와 같은 방법은 코드의 오류를 줄이고, 유지보수를 용이하게 하며, 테스트하기 쉽게 만드는 등 여러 면에서 이점을 제공합니다. 리팩터링의 핵심은 기능의 변경 없이 코드 구조를 개선하여, 장기적으로 코드의 품질을 높이는 것입니다.

조건 산술 적용의 다른 자바 예시 코드는 없어??

"리팩터링 규칙: 순수 조건 사용"은 코드 리팩터링에서 조건문을 더 명확하고 순수한 형태로 만드는 기법을 말합니다. 이 기법은 조건문 내에서 발생할 수 있는 부수 효과(Side Effects)를 제거하고, 조건 로직을 단순화하여 코드의 가독성과 신뢰성을 높이는 데 초점을 맞춥니다.

순수 조건 사용의 주요 원칙은 다음과 같습니다:

1. 부수 효과 제거: 조건문 내에서는 어떠한 부수 효과도 발생시키지 않아야 합니다. 즉, 조건문의 평가 과정에서 변수의 상태를 변경하거나 외부 시스템과 상호 작용하는 일이 없어야 합니다.
2. 조건의 명확성: 조건문은 그 자체로 명확하고 이해하기 쉬워야 합니다. 복잡한 로직이나 불필요한 계산은 피하고, 조건의 의도를 명확하게 전달할 수 있어야 합니다.
3. 함수나 메서드의 활용: 복잡한 조건 로직은 별도의 함수나 메서드로 추출하여, 조건문 자체는 간단하고 명확하게 유지될 수 있도록 합니다.

예를 들어, 다음과 같은 조건문이 있다고 가정해 봅시다:

if (getUserAge(user) > 18 && user.isActive() && updateUserLastActiveTime(user)) {
    // ...
}

이 조건문은 updateUserLastActiveTime(user)라는 부수 효과를 발생시키고 있습니다. 이를 순수 조건 사용 원칙에 맞게 리팩터링하면, 부수 효과를 발생시키는 로직은 조건문 밖으로 이동하고, 조건문 자체는 다음과 같이 순수하게 변경할 수 있습니다:

if (getUserAge(user) > 18 && user.isActive()) {
    updateUserLastActiveTime(user);
    // ...
}

이렇게 리팩터링하면, 코드의 의도가 더 명확해지고, 조건문의 평가가 부수 효과에 영향을 받지 않게 되어 코드의 신뢰성이 향상됩니다. 또한, 테스트와 유지보수가 더 쉬워지는 장점도 있습니다.

조건은 조건 로직은 로직 이렇게 순수 목적을 명확히 하는 리팩터링이구만

맞습니다, "순수 조건 사용" 리팩터링은 조건 로직과 실행 로직을 명확히 분리하여, 각각의 목적을 더욱 명확하게 하는 리팩터링 방법입니다. 이 방식은 코드의 가독성을 향상시키고, 부수 효과로 인한 잠재적인 버그를 줄이며, 코드의 유지보수를 용이하게 합니다. 주요 원칙과 장점을 살펴보면 다음과 같습니다:

1. 조건과 실행의 분리: 조건문 내에서는 단순히 조건을 평가하는 역할만 수행하고, 실제 로직의 실행은 조건문 밖에서 이루어지도록 합니다. 이는 조건문의 목적을 순수하게 유지하는데 도움이 됩니다.
2. 부수 효과 제거: 조건문에서 변수의 상태를 변경하거나 외부 시스템과의 상호작용 같은 부수 효과를 발생시키지 않도록 함으로써, 코드의 예측 가능성과 신뢰성을 높입니다.
3. 가독성 향상: 조건문이 단순하고 명확해지면, 다른 개발자들이 코드를 이해하기 쉬워집니다. 이는 코드의 가독성을 크게 향상시킵니다.
4. 테스트 용이성: 순수한 조건문은 테스트하기 쉽습니다. 조건 로직과 실행 로직이 분리되어 있기 때문에, 각각을 독립적으로 테스트할 수 있습니다.
5. 유지보수성 증가: 조건 로직이 단순해지면, 나중에 변경이나 확장이 필요할 때 코드를 수정하기가 더 쉬워집니다.

이러한 리팩터링 방식은 코드의 품질을 높이고, 장기적인 관점에서 개발 프로젝트의 효율성을 증가시키는데 크게 기여합니다. "조건은 조건대로, 로직은 로직대로"라는 원칙을 통해, 코드를 더욱 명확하고 관리하기 쉬운 형태로 만들 수 있습니다.

5.4 클래스 간의 코드 통합

"리팩터링에서 클래스 간의 코드 통합"은 서로 관련된 여러 클래스 사이에서 중복되는 코드를 제거하고, 이를 공통의 클래스나 구조로 통합하는 리팩터링 방법입니다. 이 과정은 코드의 중복을 줄이고, 가독성과 유지보수성을 향상시키며, 전체적인 코드의 일관성을 높이는 데 목적이 있습니다. 클래스 간의 코드 통합은 다음과 같은 절차로 진행됩니다:

1. 중복 코드 식별: 먼저, 다른 클래스들 사이에 중복되는 코드를 식별합니다. 이는 비슷한 메서드, 필드, 혹은 로직일 수 있습니다.
2. 공통 클래스 또는 메서드 생성: 중복된 코드를 공통의 클래스나 메서드로 추출합니다. 이렇게 함으로써, 동일한 코드를 여러 곳에서 재사용할 수 있게 됩니다.
3. 상속 또는 컴포지션 사용: 중복된 코드를 처리하기 위해 상속(inheritance) 또는 컴포지션(composition)을 적용할 수 있습니다. 상속은 코드의 재사용성을 높이고, 컴포지션은 더 유연한 코드 구조를 제공합니다.
4. 코드 재구성 및 통합: 중복된 코드를 새로운 클래스나 메서드로 옮기고, 원래의 클래스들이 이를 사용하도록 코드를 재구성합니다.
5. 테스트 및 검증: 코드의 변경 후에는, 리팩터링한 코드가 기존의 기능을 올바르게 수행하는지 테스트를 통해 검증합니다.

예를 들어, Cat 클래스와 Dog 클래스가 모두 eat과 sleep 메서드를 가지고 있다면, 이 메서드들을 Animal이라는 새로운 슈퍼클래스로 추출하고, Cat과 Dog가 Animal을 상속받도록 할 수 있습니다. 이렇게 하면, eat과 sleep 메서드의 중복을 제거하고, 두 클래스의 공통 기능을 쉽게 관리할 수 있습니다.

이러한 리팩터링은 코드의 재사용성을 높이고, 유지보수를 용이하게 하며, 전체적인 프로젝트의 구조를 개선하는 데 중요한 역할을 합니다. 클래스 간의 코드 통합은 복잡한 시스템에서 중복을 줄이고, 코드 베이스의 일관성을 유지하는 데 매우 유용한 리팩터링 방법입니다.

예시 자바 코드

물론입니다. 클래스 간의 코드 통합을 보여주는 자바 예시를 제공하겠습니다. 이 예시에서는 Cat 클래스와 Dog 클래스가 공통으로 가지고 있는 메서드를 Animal이라는 상위 클래스로 추출하는 과정을 보여줍니다.

먼저, 리팩터링 전 Cat 클래스와 Dog 클래스의 구조를 살펴보겠습니다:

class Cat {
    public void eat() {
        System.out.println("Cat is eating");
    }

    public void sleep() {
        System.out.println("Cat is sleeping");
    }
}

class Dog {
    public void eat() {
        System.out.println("Dog is eating");
    }

    public void sleep() {
        System.out.println("Dog is sleeping");
    }
}

여기서 eat과 sleep 메서드는 두 클래스 모두에서 중복되고 있습니다. 이를 공통의 상위 클래스인 Animal로 추출하여 중복을 제거할 수 있습니다:

class Animal {
    public void eat() {
        System.out.println("Animal is eating");
    }

    public void sleep() {
        System.out.println("Animal is sleeping");
    }
}

class Cat extends Animal {
    // Cat 특유의 메서드 및 필드
}

class Dog extends Animal {
    // Dog 특유의 메서드 및 필드
}

이제 Cat과 Dog 클래스는 Animal 클래스를 상속받아 eat과 sleep 메서드를 공유하게 되었습니다. 이렇게 함으로써, 중복된 코드를 제거하고 두 클래스의 공통 기능을 상위 클래스에서 관리할 수 있게 되었습니다.

이러한 리팩터링은 코드의 재사용성을 높이고, 유지보수를 용이하게 하며, 전체적인 코드 구조를 더 깔끔하고 효율적으로 만드는 데 도움이 됩니다. 클래스 간의 코드 통합은 특히 객체지향 프로그래밍에서 중요한 리팩터링 기법 중 하나입니다.

5.4.1 클래스 관계를 묘사하기 위한 UML 클래스 다이어그램 소개

UML(Unified Modeling Language) 클래스 다이어그램은 소프트웨어 시스템 내의 클래스들과 그들 사이의 관계를 시각적으로 표현하는 도구입니다. 클래스 다이어그램은 객체지향 시스템의 구조를 설계하고 이해하는 데 매우 유용하며, 클래스 간의 상속, 연관, 의존성 등을 명확하게 보여줍니다.

UML 클래스 다이어그램의 주요 요소는 다음과 같습니다:

1. 클래스: 클래스는 직사각형으로 표현되며, 세 부분으로 나뉩니다. 상단부에는 클래스 이름이, 중간부에는 클래스의 속성(변수), 하단부에는 클래스의 메서드(함수)가 표시됩니다.
2. 관계: 클래스들 사이의 다양한 관계를 선과 화살표로 표현합니다. 이 관계에는 상속, 연관, 집합, 의존성 등이 포함됩니다.
   • 상속(Inheritance): 상위 클래스와 하위 클래스 간의 관계를 나타냅니다. 빈 화살표로 표시되며, 화살표의 머리는 상위 클래스를 가리킵니다.
   • 연관(Association): 두 클래스 간의 연결을 나타냅니다. 일반적으로 실선으로 표시됩니다.
   • 집합(Aggregation): '전체-부분' 관계를 나타내며, 빈 마름모로 표시됩니다.
   • 합성(Composition): 더 강한 '전체-부분' 관계를 나타내며, 채워진 마름모로 표시됩니다.
   • 의존성(Dependency): 한 클래스가 다른 클래스에 의존하는 관계를 나타내며, 점선과 화살표로 표시됩니다.
3. 멀티플리시티(Multiplicity): 연관된 객체들 간의 수적 관계를 나타냅니다. 예를 들어, 한 클래스가 다른 클래스의 여러 인스턴스와 연관될 수 있음을 표시합니다.

UML 클래스 다이어그램은 시스템의 설계 단계에서 클래스 구조를 명확하게 파악하고, 개발자 간의 의사소통을 돕고, 시스템의 문서화에 유용하게 사용됩니다. 또한, 복잡한 시스템에서 클래스 간의 관계를 시각적으로 이해하는 데 큰 도움이 됩니다. 클래스 다이어그램을 통해 개발자는 시스템의 구조를 체계적으로 분석하고, 설계를 개선할 수 있는 기회를 갖게 됩니다.

좀 더 알기 쉽게 설명 해줘

UML 클래스 다이어그램은 컴퓨터 프로그램의 설계를 도와주는 그림 같은 도구입니다. 이 다이어그램을 사용하면 프로그램 안에서 서로 다른 '클래스'(클래스는 프로그래밍에서 사용되는 일종의 설계도 같은 것)들이 어떻게 연결되어 있는지 쉽게 볼 수 있습니다.

간단하게 UML 클래스 다이어그램의 주요 요소들을 설명하면 다음과 같습니다:

1. 클래스: 클래스는 사각형으로 그려지며, 보통 세 부분으로 나눠집니다. 위쪽에는 클래스의 이름이, 가운데에는 그 클래스에 속한 변수들이, 아래쪽에는 함수들이 적혀 있습니다.
2. 관계: 클래스 다이어그램에서는 클래스들 사이의 다양한 관계를 선으로 나타냅니다. 이 관계에는 '상속'이라고 해서 한 클래스가 다른 클래스의 기능을 물려받는 것, '연관'이라고 해서 두 클래스가 서로 연결되어 있는 것 등이 있습니다.
   • 상속: 화살표가 빈 삼각형으로 끝나는 선으로 표시됩니다. 이는 한 클래스가 다른 클래스로부터 속성이나 기능을 물려받았다는 것을 나타냅니다.
   • 연관: 두 클래스가 서로 어떻게 연결되어 있는지 보여주는 실선입니다.
3. 멀티플리시티: 이는 한 클래스가 다른 클래스의 몇 개의 객체와 연결되는지를 나타냅니다. 예를 들어, 한 교사가 여러 학생을 가르칠 수 있다는 관계를 표현할 때 사용합니다.

이런 식으로 UML 클래스 다이어그램은 프로그램의 구조를 시각적으로 보여주어, 프로그램을 설계하고, 개발자들 사이의 의사소통을 돕고, 프로그램을 문서화하는 데 도움을 줍니다. 쉽게 말해, UML 클래스 다이어그램은 복잡한 프로그램을 그림으로 그려서 누구나 쉽게 이해할 수 있게 도와주는 도구라고 할 수 있습니다.

5.4.2 리팩터링 패턴: 전략 패턴의 도입

"리팩터링에서 전략 패턴의 도입"은 소프트웨어 디자인에서 사용되는 중요한 리팩터링 기법 중 하나입니다. 전략 패턴은 객체의 행동(behavior)을 변경하고자 할 때 사용되며, 이를 통해 코드의 유연성을 높이고, 유지보수성을 개선하며, 복잡성을 줄일 수 있습니다.

전략 패턴은 다음과 같은 특징을 가지고 있습니다:

1. 행동의 캡슐화: 전략 패턴은 알고리즘 또는 행동을 별도의 클래스(전략 클래스)로 캡슐화합니다. 이를 통해 알고리즘을 사용하는 클라이언트 클래스와 독립적으로 알고리즘을 변경하거나 확장할 수 있습니다.
2. 전략 인터페이스 정의: 전략 클래스들이 공통으로 구현해야 할 인터페이스를 정의합니다. 이 인터페이스는 특정 행동이나 알고리즘을 위한 메서드를 선언합니다.
3. 실행 시 행동 변경: 클라이언트 클래스는 전략 인터페이스를 통해 특정 전략 객체를 사용하며, 실행 시점에서 행동을 변경할 수 있습니다. 이는 코드의 유연성을 높이고, 다양한 상황에 적응할 수 있게 해줍니다.
4. 의존성 주입: 클라이언트 클래스는 생성자나 세터 메서드를 통해 특정 전략 객체를 주입받을 수 있습니다. 이를 통해 클라이언트와 전략 클래스 사이의 의존성이 낮아지며, 테스트와 유지보수가 용이해집니다.

전략 패턴을 도입한 예시를 보면 다음과 같습니다:

interface SortingStrategy {
    void sort(List<Integer> data);
}

class QuickSortStrategy implements SortingStrategy {
    @Override
    public void sort(List<Integer> data) {
        // 퀵 정렬 알고리즘 구현
    }
}

class MergeSortStrategy implements SortingStrategy {
    @Override
    public void sort(List<Integer> data) {
        // 병합 정렬 알고리즘 구현
    }
}

class Context {
    private SortingStrategy strategy;

    public Context(SortingStrategy strategy) {
        this.strategy = strategy;
    }

    public void setStrategy(SortingStrategy strategy) {
        this.strategy = strategy;
    }

    public void sortData(List<Integer> data) {
        strategy.sort(data);
    }
}

여기서 Context 클래스는 정렬 전략을 사용합니다. 프로그램 실행 중에 setStrategy 메서드를 통해 다른 정렬 전략으로 변경할 수 있습니다. 이런 식으로 전략 패턴을 사용하면, 코드의 변경 없이도 다양한 알고리즘을 유연하게 사용할 수 있게 됩니다.

전략 패턴은 특히 알고리즘을 자주 변경하거나 확장해야 하는 경우, 또는 여러 알고리즘 중에서 조건에 따라 선택해야 할 때 매우 유용한 디자인 패턴입니다.

전략 패턴

전략 패턴(Strategy Pattern)은 소프트웨어 디자인 패턴 중 하나로, 알고리즘을 객체의 행동으로 캡슐화하여, 실행 중에 알고리즘을 쉽게 바꿀 수 있도록 하는 패턴입니다. 이 패턴은 객체의 행동을 정의하는 부분을 별도의 클래스로 분리하여, 동일한 작업을 수행할 때 다양한 방식을 채택할 수 있게 합니다.

전략 패턴의 주요 구성 요소는 다음과 같습니다:

1. 전략 인터페이스(Strategy Interface): 이 인터페이스는 전략 패턴에서 사용될 다양한 알고리즘(행동)들의 공통 기능을 정의합니다.
2. 구체적 전략(Concrete Strategies): 전략 인터페이스를 구현하는 클래스들입니다. 각각의 구체적 전략 클래스는 인터페이스에 정의된 알고리즘을 실제로 구현합니다.
3. 콘텍스트(Context): 콘텍스트는 전략 인터페이스를 사용하여 특정 전략을 적용합니다. 실행 중에 전략을 변경할 수 있으며, 이를 통해 다른 알고리즘을 적용할 수 있습니다.

전략 패턴의 장점은 다음과 같습니다:

• 유연성: 실행 중에 알고리즘을 쉽게 변경할 수 있어, 다양한 상황에 대응하는 유연한 코드를 작성할 수 있습니다.
• 확장성: 새로운 전략을 추가하더라도 기존의 코드를 변경할 필요가 없어, 시스템을 쉽게 확장할 수 있습니다.
• 재사용성: 전략 인터페이스를 구현하는 다양한 알고리즘들은 다른 문맥에서 재사용될 수 있습니다.
• 단위 테스트 용이성: 각 전략을 독립적으로 테스트할 수 있어, 단위 테스트가 용이합니다.

예를 들어, 정렬 알고리즘을 적용하는 프로그램에서 전략 패턴을 사용하면, 퀵 정렬, 병합 정렬, 버블 정렬 등 다양한 정렬 알고리즘을 상황에 따라 쉽게 바꿀 수 있습니다. 이를 통해 알고리즘의 변경이나 추가가 필요할 때 기존 코드를 수정하지 않고도 새로운 알고리즘을 적용할 수 있습니다.

전략 패턴 예시 코드

전략 패턴의 자바 코드 예시를 드리겠습니다. 이 예시에서는 간단한 로그 처리 시스템을 가정하고, 로그 메시지를 다양한 방식으로 처리할 수 있는 전략 패턴을 적용할 것입니다.

1. *전략 인터페이스(Strategy Interface)**를 정의합니다. 이 인터페이스는 로그 처리를 위한 메서드를 선언합니다.

public interface LogStrategy {
    void execute(String message);
}

1. *구체적 전략(Concrete Strategies)**를 구현합니다. 예를 들어, 콘솔에 로그를 출력하는 전략과 파일에 로그를 기록하는 전략을 만들 수 있습니다.

public class ConsoleLogStrategy implements LogStrategy {
    @Override
    public void execute(String message) {
        System.out.println("Console log: " + message);
    }
}

public class FileLogStrategy implements LogStrategy {
    @Override
    public void execute(String message) {
        // 파일에 로그를 기록하는 로직 구현
        System.out.println("File log: " + message);
    }
}

1. 콘텍스트(Context) 클래스를 만듭니다. 이 클래스는 전략 인터페이스를 사용하고, 실행 중에 전략을 변경할 수 있습니다.

public class Logger {
    private LogStrategy logStrategy;

    public Logger(LogStrategy logStrategy) {
        this.logStrategy = logStrategy;
    }

    public void setLogStrategy(LogStrategy logStrategy) {
        this.logStrategy = logStrategy;
    }

    public void logMessage(String message) {
        logStrategy.execute(message);
    }
}

1. 클라이언트 코드에서 전략 패턴을 사용합니다. 실행 중에 로그 전략을 변경할 수 있습니다.

public class StrategyPatternDemo {
    public static void main(String[] args) {
        Logger logger = new Logger(new ConsoleLogStrategy());
        logger.logMessage("This is a test message");

        // 실행 중에 로그 전략을 변경
        logger.setLogStrategy(new FileLogStrategy());
        logger.logMessage("This is another test message");
    }
}

이 예시에서는 Logger 클래스가 전략 패턴의 콘텍스트 역할을 하며, LogStrategy 인터페이스를 구현하는 ConsoleLogStrategy와 FileLogStrategy 클래스는 구체적인 로그 처리 전략을 제공합니다. 클라이언트 코드에서는 Logger 객체를 생성할 때 원하는 로그 전략을 주입하고, 필요에 따라 실행 중에 전략을 변경할 수 있습니다. 이러한 방식으로 전략 패턴은 로그 처리 방식을 유연하게 변경할 수 있는 구조를 제공합니다.

5.4.3. 규칙: 구현체가 하나뿐인 인터페이스를 만들지 말 것

"구현체가 하나뿐인 인터페이스를 만들지 말 것"은 소프트웨어 설계에서 지켜야 할 중요한 규칙 중 하나입니다. 이 규칙은 효율적이고 유지보수가 용이한 코드를 작성하기 위해 고려되어야 합니다.

인터페이스는 다양한 구현체를 가질 수 있는 계약(Contract)으로, 여러 구현 방식을 추상화하여 제공합니다. 그러나 구현체가 하나뿐인 인터페이스는 다음과 같은 문제를 일으킬 수 있습니다:

1. 과도한 추상화: 인터페이스가 단 하나의 구현체만을 가질 경우, 이는 불필요한 추상화로 간주될 수 있습니다. 이로 인해 코드의 복잡성이 증가하고, 읽고 이해하기 어려운 코드가 될 수 있습니다.
2. 유지보수의 어려움: 불필요한 인터페이스는 시스템의 구조를 복잡하게 만들어, 유지보수를 더 어렵게 만듭니다. 코드 변경 시 여러 계층을 거쳐야 하므로, 개발 효율성이 떨어질 수 있습니다.
3. 확장성 제한: 인터페이스가 하나의 구현체에만 종속될 경우, 시스템의 확장성이 제한될 수 있습니다. 인터페이스는 다양한 구현 방식을 수용할 수 있어야 하며, 그렇지 않으면 인터페이스의 장점이 축소됩니다.

그러나, 모든 상황에서 이 규칙을 엄격하게 적용하는 것은 아닙니다. 예를 들어, 미래에 다른 구현체가 추가될 가능성이 있거나, 특정 구조(예: 플러그인 시스템, 테스트를 위한 목(Mock) 객체)를 위해 인터페이스를 사용하는 경우에는 예외일 수 있습니다.

따라서, 인터페이스를 설계할 때는 현재와 미래의 사용 사례를 고려하여, 꼭 필요한 경우에만 인터페이스를 정의하는 것이 중요합니다. 이는 코드의 간결성과 명확성을 유지하고, 유지보수를 용이하게 하는 데 도움이 됩니다.

5.4.4. 리팩터링 패턴: 구현에서 인터페이스 추출

"리팩터링 패턴: 구현에서 인터페이스 추출"은 기존의 클래스 구현으로부터 인터페이스를 분리하여 시스템의 유연성을 증가시키고, 결합도를 낮추며, 확장성을 향상시키는 리팩터링 기법입니다. 이 패턴은 특히 시스템이 확장될 가능성이 있거나, 다양한 구현이 필요할 때 유용합니다.

이 리팩터링 과정은 다음과 같은 단계로 진행됩니다:

1. 기존 클래스 분석: 먼저, 인터페이스를 추출할 클래스의 구현을 분석합니다. 어떤 메서드들이 외부에 공개되어야 할지, 어떤 기능이 인터페이스에 포함되어야 할지 결정합니다.
2. 인터페이스 생성: 분석된 메서드들을 포함하는 새로운 인터페이스를 생성합니다. 이 인터페이스는 기존 클래스의 공개 메서드 시그니처를 그대로 사용합니다.
3. 기존 클래스 수정: 기존 클래스가 새로 생성된 인터페이스를 구현하도록 변경합니다. 이 과정에서 클래스의 구현은 그대로 유지되며, 인터페이스를 통해 외부에 노출됩니다.
4. 클라이언트 코드 수정: 인터페이스를 사용하는 클라이언트 코드를 수정하여, 구체적인 클래스 대신 인터페이스를 참조하도록 합니다. 이렇게 함으로써 결합도가 낮아지고, 나중에 다른 구현으로 쉽게 교체할 수 있게 됩니다.

예를 들어, 다음과 같은 PaymentProcessor 클래스가 있다고 가정해 보겠습니다:

public class PaymentProcessor {
    public void processCreditCardPayment(String cardNumber, double amount) {
        // 신용카드 결제 처리 로직
    }

    public void processDebitCardPayment(String cardNumber, double amount) {
        // 직불카드 결제 처리 로직
    }
}

이 클래스에서 인터페이스를 추출하면 다음과 같이 됩니다:

public interface PaymentProcessor {
    void processCreditCardPayment(String cardNumber, double amount);
    void processDebitCardPayment(String cardNumber, double amount);
}

public class DefaultPaymentProcessor implements PaymentProcessor {
    @Override
    public void processCreditCardPayment(String cardNumber, double amount) {
        // 신용카드 결제 처리 로직
    }

    @Override
    public void processDebitCardPayment(String cardNumber, double amount) {
        // 직불카드 결제 처리 로직
    }
}

이러한 방식으로 리팩터링을 수행하면, 향후 다른 결제 방식을 추가할 때 PaymentProcessor 인터페이스를 구현하는 새로운 클래스를 만들기만 하면 되므로, 시스템의 확장성이 크게 향상됩니다. 또한, 인터페이스를 사용함으로써 결합도가 낮아지고 유연성이 증가합니다.

인터페이스가 구현되어 있지 않은 코드들에서 인터페이스를 추출함으로써 인터페이스가 있는 장점을 이용 할 수 있다는 장점이 있네

맞습니다, 기존에 인터페이스가 없는 코드에서 인터페이스를 추출함으로써, 인터페이스를 사용했을 때 얻을 수 있는 다양한 이점을 활용할 수 있습니다. 이러한 리팩터링 방식은 코드의 구조를 개선하고, 더 나은 소프트웨어 설계 원칙을 적용하는 데 도움이 됩니다. 인터페이스 추출의 주요 이점은 다음과 같습니다:

1. 유연성 증가: 인터페이스를 통해 구체적인 구현을 추상화함으로써, 코드의 유연성이 크게 증가합니다. 이는 다양한 구현체를 쉽게 교체할 수 있게 하며, 상황에 따라 적합한 구현을 선택할 수 있는 가능성을 제공합니다.
2. 결합도 감소: 인터페이스를 사용하면 클래스 간의 결합도가 낮아집니다. 클래스가 직접 다른 클래스에 의존하는 대신 인터페이스에 의존하게 되면, 한 부분의 변경이 다른 부분에 미치는 영향이 줄어들어 시스템의 안정성이 증가합니다.
3. 테스트와 유지보수의 용이성: 인터페이스를 사용하면 단위 테스트가 용이해집니다. 테스트 도중 인터페이스의 구현체를 목(Mock) 객체로 쉽게 대체할 수 있으며, 이는 테스트의 단순화와 정확성을 높이는 데 기여합니다. 또한, 인터페이스를 사용함으로써 유지보수가 더 쉬워지고 코드 변경 시 발생할 수 있는 리스크가 감소합니다.
4. 확장성과 재사용성 향상: 인터페이스를 도입하면 시스템의 확장성이 향상됩니다. 새로운 기능이 필요할 때 기존 인터페이스를 구현하는 새로운 클래스를 추가하기만 하면 되므로, 기존 코드의 큰 수정 없이도 새로운 기능을 쉽게 추가할 수 있습니다. 또한, 인터페이스를 통한 재사용성이 높아져, 보다 효율적인 코드 작성이 가능해집니다.

이러한 이점들로 인해, 인터페이스를 적극적으로 활용하는 것은 객체지향 프로그래밍에서 중요한 부분입니다. 인터페이스 추출은 코드의 품질을 높이고, 프로젝트의 유연성과 확장성을 개선하는 데 큰 도움이 됩니다.

5.5 유사 함수 통합하기 & 5.6 유사한 코드 통합하기

"리팩터링 유사 함수 통합하기"와 "유사한 코드 통합하기"는 코드 중복을 제거하고, 프로그램의 구조를 개선하기 위한 리팩터링 기법입니다. 이러한 리팩터링 접근 방식은 코드의 가독성을 높이고, 유지보수를 용이하게 하며, 오류 가능성을 줄이는 데 도움이 됩니다.

유사 함수 통합하기

이 기법은 비슷한 기능을 하는 여러 함수 또는 메서드를 하나의 함수나 메서드로 통합하는 것을 말합니다. 유사 함수 통합의 과정은 다음과 같습니다:

1. 유사성 분석: 먼저, 통합할 유사 함수들을 분석하여 공통적인 부분과 차이점을 식별합니다.
2. 함수 통합: 공통 코드를 하나의 함수나 메서드로 통합합니다. 차이점이 있는 부분은 파라미터나 조건문을 통해 처리할 수 있습니다.
3. 테스트 및 검증: 통합된 함수나 메서드가 원래의 기능을 올바르게 수행하는지 테스트하여 검증합니다.

유사한 코드 통합하기

유사한 코드 통합은 코드 블록이나 구현의 중복을 제거하는 리팩터링 기법입니다. 이 방법은 다음과 같은 단계로 진행됩니다:

1. 중복 코드 식별: 중복되거나 유사한 코드 블록을 식별합니다.
2. 코드 추출 및 통합: 중복된 코드를 별도의 메서드나 함수로 추출하고, 이를 여러 곳에서 재사용합니다.
3. 테스트 및 검증: 추출 및 통합된 코드가 원래의 기능을 정상적으로 수행하는지 테스트하여 검증합니다.

두 기법 모두 목적은 코드의 중복을 최소화하고, 가독성 및 유지보수성을 향상시키는 것입니다. 또한, 이러한 리팩터링은 장기적인 관점에서 프로젝트의 품질을 향상시키고, 개발 팀의 효율성을 증가시키는 데 크게 기여합니다. 코드의 재사용성과 일관성을 높이고, 오류 발생 가능성을 줄이며, 향후 확장성을 고려하는 것이 이러한 리팩터링의 핵심입니다.