Cosa c'è di astratto nella fabbrica astratta?

Bene, probabilmente vale la pena menzionare che ci sono due modelli qui: Pattern metodo di fabbrica e Modello di fabbrica astratto .

Lo schema del metodo di fabbrica è ciò che descrivi. Una classe real è responsabile della creazione di tutte le istanze. Non c'è nulla di astratto in questo. Il vantaggio è che la creazione delle istanze è separata dal loro utilizzo.

Ma cosa succede quando la creazione di ogni istanza diventa selvaggiamente diversa da quella successiva e / o la tua classe è ingombra di gigantesche catene if-else?

Il modello di fabbrica astratto è il prossimo passo che affronta questo problema. Rende anche la creazione di ogni oggetto completamente flessibile e potenzialmente nella sua stessa classe. Ad esempio, anziché connettersi a un database, ognuno con i propri parametri e la stringa di connessione, tutti concatenati in una singola classe factory complessa, si creano implementazioni di una fabbrica astratta, ciascuna implementazione focalizzata su un singolo database.

Il vantaggio in definitiva rimane lo stesso, tuttavia è possibile farlo senza avere una classe factory reale eccessivamente complicata. Ovviamente, se puoi fare solo con la classe del metodo factory, usa questo. Non è necessario implementare un modello di fabbrica astratto quando il modello di metodo di fabbrica andrà bene.

Quindi, per rispondere alla tua domanda, il motivo per cui chiameresti il modello astratto di fabbrica astratto è perché ogni fabbrica stessa deriva da una fabbrica astratta.

Per quanto riguarda la denominazione del modello di fabbrica abstract : il movimento del modello di progettazione e in particolare il libro Design Patterns era incentrato su Smalltalk e C ++ e precede la popolarità di Java. Né Smalltalk né C ++ hanno interfacce. Smalltalk come linguaggio dinamico simile a Python non ha bisogno di interfacce esplicite, e C ++ semplicemente non aveva un concetto con quel nome.

Invece, C ++ usa classi astratte che contengono solo metodi virtuali puri, cioè metodi che non hanno implementazione e devono essere sovrascritti nelle classi figlie. Si noti inoltre che C ++ ha ereditarietà multipla, quindi è possibile ereditare da più classi di base astratte, a differenza ad es. Java.

Pertanto, la terminologia di Abstract versus Concrete ha molto senso nel contesto di questi modelli di design. L'introduzione del libro Design Patterns illustra esplicitamente la differenza:

An abstract class is one whose main purpose is to define a common interface for its subclasses. An abstract class will defer some or all of its implementation to operations defined in subclasses; hence an abstract class cannot be instantiated. The operations that an abstract class declares but doesn't implement are called abstract operations. Classes that aren't abstract are called concrete classes.

Dal punto di vista della storia della lingua, le interfacce come un concetto separato dalle classi sono necessarie solo in linguaggi OOP a ereditarietà tipizzati in modo statico come Java. Esiste un desiderio comprensibile di evitare la complessità dell'ereditarietà multipla, ma l'ereditarietà dell'interfaccia multipla è assolutamente necessaria per implementare progetti OOP non banali. Curiosamente, i linguaggi più recenti come Go e Rust eliminano completamente le classi e mantengono solo l'ereditarietà di caratteristiche e interfacce, probabilmente una forma più pura di OOP.