L'ereditarietà del contesto, come mostrato dall'esempio Duck di Head First Design Patterns, è irrilevante rispetto al modello di strategia?

Sì, penso che tu sia sulla strada giusta. La classe che usa il modello di strategia non deve essere una sottoclasse. Il modello di strategia è un alternativa all'ereditarietà per il riutilizzo del codice. Questo torna al confronto ancora più ampio tra ereditarietà e composizione.

Da Modelli di progettazione: elementi di OOP riutilizzabile devi utilizzare il modello di strategia per

• Evita un'esplosione di sottoclassi (a causa di combinazioni di comportamenti)
• Se è necessario sostituire il comportamento in fase di esecuzione

Se si utilizza l'ereditarietà per implementare comportamenti di Quack and Fly si otterrebbe che tutte queste sottoclassi rappresentino tutte le combinazioni di comportamenti.

• FlyableQuackableDuck
• FlyableSqeakableDuck
• FlyableMuteDuck
• NoFlyQuackableDuck
• NoFlySqueakableDuck
• NoFlyMuteDuck

Avere così tante sottoclassi rende più difficile mantenere il motivo per cui in questo caso viene preferito il modello di strategia. Hai solo bisogno di due proprietà che incapsulano Flyability e Quackability e puoi combinarle senza creare nuove classi.

Hai anche menzionato il vantaggio in termini di runtime se le condizioni meteorologiche hanno cambiato la proprietà Fly's duck potrebbe essere sostituita con un oggetto NoFly a causa delle condizioni.

Questo è coerente con il consiglio di favorire la composizione sull'ereditarietà quando possibile.

Could I further simplify this example by just having a Duck class (no derived classes)? Then when implementing one duck object it can be assigned different behaviors based on certain circumstances that aren't dependent on its own object type.

Certamente. Per l'ispirazione, dai un'occhiata a Head First Oriented Object Analysis and Design . C'è una "Rick's Guitars" che mostra un'esplosione di sottoclassi Instrument (musicali). Per rimediare a tutto questo comportamento variabile è racchiuso in una classe "specifica", osservando il principio di incapsulare ciò che varia .

Fabbrica astratta - Costruzione basata sul contesto

Ecco lo schema . A proposito, nota che usa la strategia stessa.

Concentrarsi sul concetto, non sull'implementazione ... Potresti avere un "WeatherFactory" che crea oggetti specificazioni basati su condizioni soleggiate o piovose, ecc.

Potresti avere "fabbriche di fabbriche" per costruire queste cose "NoFlyInFogQuackableMallard". E in effetti, questo è ciò di cui tratta il modello Abstract Factory. Quindi forse un DuckFactory per creare tipi di anatre generali, quindi un WeatherFactory per dargli un comportamento da nebbia anatre-specifico.