Perché la mia classe è peggiore della gerarchia delle lezioni nel libro (OOP per principianti)?

Sto leggendo PHP Objects, Patterns and Practice . L'autore sta cercando di modellare una lezione in un college. L'obiettivo è produrre il tipo di lezione (lezione o seminario) e le spese per la lezione a seconda che si tratti di una lezione oraria o a prezzo fisso. Quindi l'output dovrebbe essere

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

quando l'ingresso è il seguente:

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

Ho scritto questo:

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 />";
}

Ma secondo il libro, ho torto (sono abbastanza sicuro di esserlo anche io). Invece, l'autore ha fornito una grande gerarchia di classi come soluzione. In un capitolo precedente, l'autore ha dichiarato i seguenti "quattro segni" come il momento in cui dovrei considerare di cambiare la mia struttura di classe:

• Duplicazione del codice
• La classe che sapeva troppo del suo contesto
• Il tuttofare - le classi che cercano di fare molte cose
• Dichiarazioni condizionali

L'unico problema che posso vedere sono le dichiarazioni condizionali, e anche quello in modo vago - quindi perché rifattorlo? Quali problemi pensi possano sorgere in futuro che non ho previsto?

Aggiornamento : ho dimenticato di menzionare - questa è la struttura di classe che l'autore ha fornito come soluzione - il modello di strategia :

È divertente che il libro non lo affermi chiaramente, ma il motivo per cui favorisce una gerarchia di classi se le istruzioni all'interno della stessa classe sono probabilmente il principio Open / Closed Questa regola di progettazione software ampiamente nota afferma che una classe dovrebbe essere chiusa a modifica ma aperto per l'estensione.

Nel tuo esempio, aggiungere un nuovo tipo di lezione significherebbe cambiare il codice sorgente della lezione, rendendolo fragile e soggetto a regressione. Se avessi una classe base e una derivata per ogni tipo di lezione, dovresti invece semplicemente aggiungere un'altra sottoclasse, generalmente considerata più pulita.

Puoi mettere quella regola nella sezione "Dichiarazioni condizionali" se vuoi, tuttavia ritengo che il "cartello" sia un po 'vago. Se le dichiarazioni sono generalmente solo odori di codice, sintomi. Possono derivare da una vasta gamma di decisioni di progettazione sbagliate.

Immagino che ciò che il libro mira a insegnare sia evitare cose come:

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

La mia interpretazione del libro è che dovresti avere tre classi:

• AbstractLesson
• HourlyRateLesson
• FixedRateLesson

È quindi necessario reimplementare la costfunzione su entrambe le sottoclassi.

La mia opinione personale

per casi semplici come quelli: no. È strano che il tuo libro favorisca una gerarchia di classe più profonda per evitare semplici dichiarazioni condizionali. Inoltre, con le tue specifiche di input, Lessondovrà essere una factory con una spedizione che è una dichiarazione condizionale. Quindi con la soluzione del libro avrai:

• 3 lezioni invece di 1
• 1 livello di eredità anziché 0
• lo stesso numero di dichiarazioni condizionali

Questa è una maggiore complessità senza alcun vantaggio aggiunto.

L'esempio nel libro è piuttosto strano. Dalla tua domanda, la dichiarazione originale è:

L'obiettivo è produrre il tipo di lezione (lezione o seminario) e gli addebiti per la lezione a seconda che si tratti di una lezione oraria oa prezzo fisso.

che, nel contesto di un capitolo su OOP, significherebbe che probabilmente l'autore vuole che tu abbia la seguente struttura:

+ abstract Lesson
    - Lecture inherits Lesson
    - Seminar inherits Lesson

+ abstract Charge
    - HourlyCharge inherits Charge
    - FixedCharge inherits Charge

Ma poi arriva l'input che hai citato:

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

vale a dire qualcosa che si chiama codice tipicamente stringa e che, onestamente, in questo contesto in cui il lettore è destinato a imparare OOP, è orribile.

Questo significa anche che se ho ragione sull'intenzione dell'autore del libro (cioè creando quelle classi astratte ed ereditate che ho elencato sopra), questo porterà a un codice duplicato e piuttosto illeggibile e brutto:

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.

Per quanto riguarda i "pannelli":

• Duplicazione del codice

  Il tuo codice non ha duplicazioni. Il codice che l'autore si aspetta che tu scriva lo fa.

• La classe che sapeva troppo del suo contesto

  La tua classe passa semplicemente le stringhe dall'input all'output e non sa nulla. Il codice previsto d'altra parte può essere criticato per sapere troppo.

• The Jack of All Trades - Classi che cercano di fare molte cose

  Ancora una volta, stai solo passando le stringhe, niente di più.

• Dichiarazioni condizionali

  C'è un'istruzione condizionale nel tuo codice. È leggibile e facile da capire.

Forse, in effetti, l'autore si aspettava che tu scrivessi un codice molto più refactored di quello con sei classi sopra. Ad esempio, è possibile utilizzare il modello di fabbrica per lezioni e addebiti, ecc.

+ 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`.

In questo caso, finirai con nove classi, che saranno un perfetto esempio di sovrastruttura .

Invece, hai finito con un codice facile da capire e pulito, che è dieci volte più breve.

Prima di tutto puoi cambiare "numeri magici" come 30 e 5 nella funzione cost () in variabili più significative :)

E ad essere sincero, penso che non dovresti preoccuparti di questo. Quando dovrai cambiare la classe, la cambierai. Prova prima a creare valore, poi passa alla rifattorizzazione.

E perché pensi di avere torto? Questa lezione non è "abbastanza buona" per te? Perché sei preoccupato per qualche libro;)

Non è assolutamente necessario implementare classi aggiuntive. Hai qualche MAGIC_NUMBERproblema con la tua cost()funzione, ma il gioco è fatto. Qualsiasi altra cosa è un enorme ingegnerizzazione eccessiva. Tuttavia, è purtroppo comune che vengano dati dei pessimi consigli: Circle eredita Shape, per esempio. Sicuramente non è in alcun modo efficace derivare una classe per la semplice eredità di una funzione. È possibile utilizzare un approccio funzionale per personalizzarlo invece.