내 수업이 책의 클래스 계층 구조보다 더 나쁜 이유는 무엇입니까 (초보자 OOP)?

PHP Objects, Patterns 및 Practice을 읽고 있습니다. 저자는 대학에서 수업을 모델링하려고합니다. 목표는 수업 유형 (강의 또는 세미나)과 시간당 또는 고정 가격 수업인지에 따라 수업 요금을 출력하는 것입니다. 따라서 출력은

Lesson charge 20. Charge type: hourly rate. Lesson type: seminar.
Lesson charge 30. Charge type: fixed rate. Lesson type: lecture.

입력이 다음과 같은 경우 :

$lessons[] = new Lesson('hourly rate', 4, 'seminar');
$lessons[] = new Lesson('fixed rate', null, 'lecture');

나는 이것을 썼다 :

class Lesson {
    private $chargeType;
    private $duration;
    private $lessonType;

    public function __construct($chargeType, $duration, $lessonType) {
        $this->chargeType = $chargeType;
        $this->duration = $duration;
        $this->lessonType = $lessonType;
    }

    public function getChargeType() {
        return $this->getChargeType;
    }

    public function getLessonType() {
        return $this->getLessonType;
    }

    public function cost() {
        if($this->chargeType == 'fixed rate') {
            return "30";
        } else {
            return $this->duration * 5;
        }
    }
}

$lessons[] = new Lesson('hourly rate', 4, 'seminar');
$lessons[] = new Lesson('fixed rate', null, 'lecture');

foreach($lessons as $lesson) {
    print "Lesson charge {$lesson->cost()}.";
    print " Charge type: {$lesson->getChargeType()}.";
    print " Lesson type: {$lesson->getLessonType()}.";
    print "<br />";
}

그러나 그 책에 따르면, 나는 틀렸다 (나도 확실하다). 대신 저자는 솔루션으로 큰 계층의 클래스를 제공했습니다. 이전 장에서 필자는 수업 구조 변경을 고려해야 할 시점으로 다음과 같은 '네 개의 푯말'을 언급했습니다.

• 코드 복제
• 상황에 대해 너무 많이 알고있는 반
• 모든 거래 의 잭 -많은 일을하려고하는 수업
• 조건문

내가 볼 수있는 유일한 문제는 조건문이며 모호한 방식입니다. 왜 리팩토링합니까? 내가 예상하지 못한 미래에 어떤 문제가 발생할 수 있다고 생각합니까?

업데이트 : 언급을 잊었습니다. 이것은 저자가 솔루션으로 제공 한 클래스 구조입니다- 전략 패턴 :

이 책에 명확하게 언급되어 있지 않은 것은 재밌지 만, 같은 클래스 내부의 문장이 공개 / 폐쇄 원칙 인 경우 클래스 계층 구조를 선호하는 이유는 이 널리 알려진 소프트웨어 설계 규칙은 클래스를 수정하지만 확장을 위해 열려 있습니다.

예를 들어, 새로운 수업 유형을 추가하면 수업 수업의 소스 코드가 변경되어 깨지기 쉽고 회귀가 발생하기 쉽습니다. 각 수업 유형마다 기본 수업과 파생 상품이 하나있는 경우 다른 하위 수업을 추가하면됩니다 (일반적으로 더 깔끔한 것으로 간주 됨).

원한다면이 규칙을 "조건문"섹션에 넣을 수 있지만 "푯말"이 약간 모호하다고 생각합니다. 진술이 일반적으로 코드 냄새, 증상 인 경우. 다양한 잘못된 설계 결정으로 인해 발생할 수 있습니다.

이 책이 가르치는 목표는 다음과 같은 것을 피하는 것입니다.

public function cost() {
    if($this->chargeType == 'fixed rate') {
        return "30";
    } else {
        return $this->duration * 5;
    }
}

이 책에 대한 나의 해석은 세 가지 수업이 필요하다는 것입니다.

• 초록
• 시간별 수업
• 고정 등급 수업

그런 다음 cost두 서브 클래스 모두 에서 함수 를 다시 구현해야합니다 .

내 개인적인 의견

그런 간단한 경우 :하지 마십시오. 간단한 조건문을 피하기 위해 책이 더 깊은 클래스 계층 구조를 선호한다는 것은 이상합니다. 또한 입력 사양 Lesson과 함께 조건문 인 디스패치가있는 팩토리 여야합니다. 따라서 도서 솔루션을 통해 다음을 얻을 수 있습니다.

• 1 대신 3 수업
• 0 대신 1 상속 수준
• 같은 수의 조건문

추가 혜택없이 더 복잡합니다.

이 책의 예는 꽤 이상합니다. 귀하의 질문에서 원래 진술은 다음과 같습니다.

목표는 레슨 유형 (강의 또는 세미나)과 시간별 또는 고정 가격 레슨인지에 따라 레슨 비용을 출력하는 것입니다.

OOP에 관한 장의 맥락에서 저자는 아마도 당신이 다음과 같은 구조를 갖기를 원할 것입니다.

+ abstract Lesson
    - Lecture inherits Lesson
    - Seminar inherits Lesson

+ abstract Charge
    - HourlyCharge inherits Charge
    - FixedCharge inherits Charge

그러나 인용 한 입력 이옵니다.

$lessons[] = new Lesson('hourly rate', 4, 'seminar');
$lessons[] = new Lesson('fixed rate', null, 'lecture');

즉 , 문자열 형식의 코드 라고 하며 ,이 맥락에서 독자가 OOP를 배우려고 할 때 정직한 것은 끔찍한 것입니다.

이것은 또한 책 저자의 의도가 옳다면 (즉, 위에서 열거 한 추상적이고 상속 된 클래스를 생성하는 경우), 이는 복제되고 읽을 수없고보기 흉한 코드로 이어질 것입니다.

const string $HourlyRate = 'hourly rate';
const string $FixedRate = 'fixed rate';

// [...]

Charge $charge;
switch ($chargeType)
{
    case $HourlyRate:
        $charge = new HourlyCharge();
        break;

    case $FixedRate:
        $charge = new FixedCharge();
        break;

    default:
        throw new ParserException('The value of chargeType is unexpected.');
}

// Imagine the similar code for lecture/seminar, and the similar code for both on output.

"푯말"에 관해서는 :

• 코드 복제

  코드에 중복이 없습니다. 저자가 작성하길 기대하는 코드는 그렇지 않습니다.

• 그의 상황에 대해 너무 많이 알고있는 반

  클래스는 입력에서 출력으로 문자열을 전달하며 전혀 알지 못합니다. 반면에 예상되는 코드는 너무 많이 알고 있다고 비난받을 수 있습니다.

• 모든 거래의 잭-많은 일을하려고하는 수업

  다시 말하지만, 당신은 단지 문자열을 전달하고 있습니다.

• 조건문

  코드에는 하나의 조건문이 있습니다. 읽기 쉽고 이해하기 쉽습니다.

실제로 저자는 위의 6 개의 클래스가있는 코드보다 훨씬 더 리팩토링 된 코드를 작성해야한다고 예상했을 수 있습니다. 예를 들어 수업 및 요금 등에 팩토리 패턴 을 사용할 수 있습니다 .

+ abstract Lesson
    - Lecture inherits Lesson
    - Seminar inherits Lesson

+ abstract Charge
    - HourlyCharge inherits Charge
    - FixedCharge inherits Charge

+ LessonFactory

+ ChargeFactory

+ Parser // Uses factories to transform the input into `Lesson`.

이 경우 9 개의 클래스가 생겨 오버 아키텍처 의 완벽한 예가 됩니다.

대신, 이해하기 쉽고 깨끗한 코드를 만들었습니다.이 코드는 10 배 짧습니다.

우선 cost () 함수에서 30과 5와 같은 "마법의 숫자"를보다 의미있는 변수로 변경할 수 있습니다. :)

그리고 솔직히 말해서, 당신은 이것에 대해 걱정해서는 안된다고 생각합니다. 수업을 변경해야 할 때 변경합니다. 먼저 가치를 창출 한 다음 리팩토링으로 넘어가십시오.

왜 당신이 틀렸다고 생각하십니까? 이 수업이 "충분하지 않습니까?" 왜 당신은 어떤 책에 대해 걱정하고 있습니까?)

추가 클래스를 구현할 필요가 전혀 없습니다. 함수 MAGIC_NUMBER에 약간의 문제가 cost()있지만 그게 전부입니다. 다른 것들은 방대한 오버 엔지니어링입니다. 그러나 불행히도 매우 나쁜 조언을하는 경우가 일반적입니다. Circle은 Shape를 상속합니다. 한 함수의 간단한 상속을 위해 클래스를 파생시키는 것은 어떤 식으로도 효율적이지 않습니다. 대신 기능적인 접근 방식을 사용하여이를 사용자 정의 할 수 있습니다.