perché il metodo factory e la classe creator non devono sempre essere astratte

Question

perché il metodo factory e la classe creator non devono sempre essere astratte

#1 da (1 voti)

2

Mentre sfoglia il libro 'Testa primi disegni di modelli' sul capitolo Modello di metodo di fabbrica, mi sono imbattuto in seguente domanda e risposta alla pp.135 (stampa data di pubblicazione del libro: 2004/10/25)

Q: Il metodo factory e il Creator sono sempre astratti?

A: No, puoi definire un metodo factory predefinito per produrre un prodotto concreto. Quindi hai sempre un mezzo per creare prodotti anche se non ci sono sottoclassi del Creatore.

Allo stesso tempo il modello del metodo factory definito dal libro come:

Il modello di metodo di fabbrica definisce un'interfaccia per la creazione di un oggetto, ma lascia che le sottoclassi decidano quale classe istanziare. Il metodo di fabbrica consente a una classe di differire l'istanzazione alle sottoclassi. pp.134

Quindi la domanda è se non ci sono sottoclassi del Creatore , allora come può il modello consentire a sottoclassi di decidere quale classe istanziare ?

EDIT: vedo i downvotes. Puoi spiegare il motivo?

design-patterns object-oriented-design factory-method

posta Istiaque Ahmed 25.10.2018 - 13:58

fonte

1 risposta

Leggi altre domande sui tag design-patterns object-oriented-design factory-method

Nei test di integrazione, si utilizzano gli oggetti di accesso ai dati per l'impostazione e la convalida o un diverso metodo di accesso ai dati? Convincere le persone a non usare una versione 3.X Python "fine vita"

score 1 · Answer 1

Definiamo un paio di termini per chiarezza:

Un metodo virtuale può essere sovrascritto da una sottoclasse.
Un metodo astratto non ha implementazione. Deve essere sovrascritto o implementato in una sottoclasse.

(Dettagli specifici della lingua: In C ++, un metodo virtuale astratto è chiamato "puro virtuale". In Java, tutti i metodi sono virtuali a meno che non siano dichiarati final .)

Lo schema del metodo factory richiede che il metodo factory possa essere sovrascritto o implementato in una sottoclasse, cioè che questo metodo sia virtual . Non richiede che la classe base dichiari questo metodo come astratto , cioè la classe base può fornire un'implementazione di quel metodo.

Se il metodo factory è astratto nella classe base, la sottoclasse deve implementarlo.
Se il metodo factory è implementato in una classe base, la sottoclasse può facoltativamente sovrascriverlo. La classe base fornisce un'implementazione predefinita.

Nel caso in cui l'implementazione del metodo sia facoltativa, ciò non toglie nulla al modello. L'aspetto importante del pattern non è che è una sottoclasse che decide quale classe istanziare, ma solo che è possibile per una sottoclasse da decidere.

Il libro Design Patterns che ha introdotto questo modello menziona esplicitamente le varianti abstract / non-abstract:

The two main variations of the Factory Method pattern are (1) the case when the Creator class is an abstract class and does not provide an implementation for the factory method it declares, and (2) the case when the Creator is a concrete class and provides a default implementation for the factory method. It's also possible to have an abstract class that defines a default implementation, but this is less common.

The first case requires subclasses to define an implementation[.] In the second case, the concrete Creator uses the factory method primarily for flexibility.