Il schema di comando utilizza l'OCP?
In un comando patter l'invocatore è solo estensibile estendendo effettivamente la classe. Se vogliamo aggiungere metodi personalizzati, possiamo creare la nostra sottoclasse o modificare il costruttore della classe base, che viola il principio di apertura / chiusura.
Il che mi porta alla domanda, è il modello di comando che utilizza OCP o non
La definizione one-liner di OCP è molto bella, anche se tende a fuorviare.
Citando l'articolo su OCP di Bob Martin originale :
It should be clear that no significant program can be 100% closed. ... In general, no matter how “closed” a module is, there will always be some kind of change against which it is not closed.
(Consiglio vivamente di leggere l'intero documento e anche Jon La critica di Skeet )
Quindi, in pratica, l'OCP è più importante per trovare il giusto equilibrio di design in modo da poter aggiungere una nuova funzionalità rompendo il minimo possibile, ad es. essere in grado di estendere e non dover modificare a fondo il codebase.
Pertanto, si tratta più di sostenere le interfacce e i contratti esistenti mentre si modifica il codice esistente.
Se un modello di comando interrompe l'OCP si basa più su dove e come viene usato rispetto al modello stesso. E dal momento che non hai fornito alcun contesto di utilizzo, la tua domanda non è realmente risolvibile.
Se incontriamo un caso in cui il nostro design, che utilizza un pattern specifico, non può soddisfare un nuovo requisito senza alcune modifiche, non significa che il pattern (non importa quale) sia cattivo e viola un buon design i principi.
Significa solo che il nostro design non è preparato per gestire con grazia tali casi.
In alcuni casi sì. Ma più spesso è un segno di uno dei due:
Potresti e dovresti considerare attentamente il tuo progetto, ma non importa quanto sia adattivo il tuo sistema, una volta i requisiti cambieranno o alcune conoscenze oscure del dominio ti obbligheranno a cambiare anche il sistema più ben progettato.
Probabilmente no. Non è possibile progettare un sistema che possa essere esteso in qualsiasi modo possibile senza compromettere altri principi di buon design. Perché tali sistemi di solito sacrificano le prestazioni e (o) la facilità di comprensione.
È un divertimento colpevole leggere su sistemi troppo adattativi simili su thedailywtf , ma non si vuole finire per mantenere uno.
Se tali modifiche verranno apportate senza alcuna considerazione sul design più grande, probabilmente sì. Ma se applichi tali modifiche con il dovuto impegno a riconsiderare e, possibilmente, a refactoring durante la fase di consolidamento allora sarai in grado di tenere sotto controllo l'entropia.
Quindi , il schema di comando viola il Open-Closed principle ?
No . Nella maggior parte dei casi sono i requisiti del sistema che rendono specifico l'uso di questo pattern non come open-closed come avremmo voluto che fosse.
L'apertura al cambiamento è una decisione strategica. Ciò significa che spetta al progettista scegliere contro quali modifiche il codice sarà aperto e contro cui non lo farà. Inoltre, abbastanza spesso, rendere il design aperto contro un cambiamento renderà più difficile aprirlo contro un altro.
Il modello di comando rende il progetto aperto contro il cambiamento di aggiunta di nuovi comportamenti con ogni comportamento utilizzabile in un contesto (ad esempio, l'impostazione comune o la rimozione di comportamenti). Non è aperto contro la modifica dei comandi esistenti (a meno che non sia possibile applicare Decorator) e contro le modifiche alla configurazione del comando.
Se ritieni che la progettazione di un progetto sia aperta contro tali modifiche, devi estendere il disegno o scartare il disegno e ricominciare da capo con i nuovi requisiti.
Leggi altre domande sui tag design-patterns open-closed-principle