L'esempio di Uncle Bob dovrebbe essere refactored ad AbstractFactory o a SimpleFactory?

2

Nel libro "Codice pulito" Robert Martin rilascia una dichiarazione sul seguente codice:

public Money calculatePay(Employee e) throws InvalidEmployeeType {   switch (e.type) {
    case COMMISSIONED:
      return calculateCommissionedPay(e);
    case HOURLY:
      return calculateHourlyPay(e);
    case SALARIED:
      return calculateSalariedPay(e);
    default:
      throw new InvalidEmployeeType(e.type);   } }

Dichiarazione: la soluzione a questo problema (vedi il Listato 3-5) consiste nel seppellire l'istruzione switch nel seminterrato di una FABBRICA ASTRATTA, 9 e non permettere a nessuno di vederlo.

Quello che non capisco è perché lo chiama Fabbrica Astratta? Se la soluzione è creare 3 sottoclassi Employee ciascuna che implementa il proprio metodo CalculatePay, allora la logica viene spostata in alto per dire il controller. Ma poi dobbiamo creare una "Fabbrica Semplice (Idiom)" non una Fabbrica Astratta come presentata nel libro originale del GOF.

La Fabbrica Astratta ha l'intento di: "Fornire un'interfaccia per creare famiglie di oggetti correlati o dipendenti senza specificare le loro classi concrete". ma chiaramente non è il caso.

    
posta danidacar 06.10.2013 - 18:34
fonte

1 risposta

3

Nell'esempio specifico, avrebbe potuto utilizzare una Simple Factory per ottenere il punto sull'istruzione switch.

Ma uno dei suoi altri punti è che dovresti cercare modi per ridurre al minimo le dipendenze. Se si dispone di codice client che utilizza la fabbrica per creare oggetti dipendenti e tale codice fa riferimento a una classe di fabbrica concreta (ovvero semplice), sarebbe un accoppiamento molto più stretto rispetto a se si fa riferimento a un'interfaccia EmployeeFactory. In questo modo, se per qualsiasi motivo, in un secondo momento, decidi che l'implementazione attuale di EmployeeFactoryImpl non è abbastanza buona per te, sarai in grado di definire semplicemente una nuova implementazione di classe factory che implementa la stessa interfaccia EmployeeFactory.

Poiché stai già utilizzando la fabbrica astratta, non è necessario toccare tutto il codice che memorizza e passa attorno all'interfaccia EmployeeFactory, che sta tornando al principio OCP, scrivere il codice il più possibile in modo che sia chiuso a modifiche costanti , perché ogni volta che modifichi qualcosa, c'è il rischio che tu lo infranga.

Quindi l'unica cosa che Uncle Bob non ha illustrato in questo esempio è che potresti aver creato "class EmployeeFactoryImpl2 implements EmployeeFactory" con un'implementazione completamente diversa del corpo del metodo makeEmployee () e che completerebbe l'esempio di GoF, ma aggiungerebbe più parti mobili all'esempio che ha lo scopo di illustrare qualcosa di completamente diverso.

L'altro porta via Clean Code (che IMO è un libro fantastico, quindi continua a leggerlo), è che i pattern sono qualcosa da tenere nella tua mente, non qualcosa da introdurre a sinistra e a destra solo perché leggi GoF . Quindi, cosa più importante di ciò che lo Zio Bob sta illustrando, e questo è un esempio perfetto, è che puoi apportare piccoli e incrementali refactoring al codice per renderlo più facile da leggere e mantenere e mentre lo fai, tieni i pattern nella parte posteriore del tuo mente perché non ha senso reinventare ciò che è già stato fatto.

In questo caso è andato direttamente alla factory astratta perché la differenza era digitando "public class EmployeeFactory" (semplice) rispetto a "public class EmployeeFactoryImpl implements EmployeeFactory" (abstract). La fabbrica astratta ti offre una posizione migliore per il futuro e YANGI non è un buon argomento qui perché questo solo posizionamento migliore ti costa una manciata di tasti senza alcuna complessità aggiuntiva.

    
risposta data 06.10.2013 - 19:06
fonte

Leggi altre domande sui tag