Model de comandă

În programarea orientată pe obiecte , modelul Command este unul dintre modelele fundamentale, inițial definit de Gang of Four .

Modelul de comandă este unul dintre modelele de proiectare care vă permite să izolați porțiunea de cod care efectuează o acțiune (posibil foarte complexă) de codul care necesită executarea acestuia; acțiunea este încapsulată în obiectul Command.

Scopul este de a face acțiunea clientului variabilă fără a cunoaște detaliile operațiunii în sine. Un alt aspect important este acela că destinatarul cererii nu poate fi decis în mod static la instanțarea comenzii, ci este obținut la momentul executării.

Structura

Exemplu

Următoarea clasă este definită într-un modul (python).

 clasa RoomHandler :
    ...

Acest lucru este destinat să aibă grijă de gestionarea camerelor unei case și, în prezent, să efectueze unele lucrări care urmează să fie efectuate.

De fapt, sunt definite unele subclase care implementează diferite lucrări care pot fi efectuate pe pereții camerelor.

 clasa Pictor ( RoomHandler )
    ...
    def actionWork ( auto , argumente ):
        "" "pictează niște pereți" ""
        ...

clasa PaperGluer ( RoomHandler )
    ...
    def actionWork ( auto , argumente ):
        "" "lipiți tapet pe niște pereți" ""
        ...

clasa ShelfMounter ( RoomHandler )
    ...
    def actionWork ( auto , argumente ):
        "" "montați rafturi pe niște pereți" ""

Această abordare are mai multe dezavantaje.

1. În fața a n locuri de muncă (acțiuni) posibile, sunt necesare diferite subclase: una pentru fiecare acțiune care trebuie implementată și una pentru fiecare posibilă compoziție a acțiunilor de bază (de exemplu, pictarea unei camere și asamblarea rafturilor de mai jos). Dacă, în schimb, acțiunile ar fi independente de Command RoomHandler, ar fi posibil să se creeze instanțe ale acestuia din urmă decât să se creeze subclasele.
2. RoomHandler conține atât codul de gestionare a camerei, cât și codul care execută acțiunile: este supraîncărcat cu responsabilitate și extinderea unei acțiuni crește complexitatea RoomHandler .
3. Testarea obiectelor cu numeroase responsabilități este în general complexă și oneroasă. Incapsularea acțiunilor din Command face posibilă testarea exclusivă a fiecărei acțiuni (eventual recurgerea la utilizarea Mock ) ceea ce simplifică foarte mult faza de testare și validare.

Mai jos este codul structurat echivalent urmând indicațiile modelului:

 comandă de clasă :

    def executați ( auto ):
        ridicați NotImplementedError

clasa PaintWallCommand ( Command )

    def executa ( self , wall ):
        "" "pictează un perete" ""

clasa GlueWallPaperCommand ( Command )

    def executa ( self , wall ):
        "" "lipiți hârtie de perete pe un perete" ""

clasa MountShelfCommand ( Command )

    def executa ( self , wall ):
        "" "montează raftul pe un perete" ""

Atât în ​​actul creării unei instanțe RoomHandler, cât și în timpul rulării , este posibil să selectați acțiunile care trebuie efectuate:

 def createRoomHandler ( auto ):
    handler = RoomHandler ()
    manipulant . addWork ( PaintWallCommand ())
    manipulant . addWork ( MountShelfCommand ())

clasa RoomHandler ( auto )
    ...
    def actionWork ( auto ):
        pentru munca în sine . getWorks ():
            munca . executa (self. getSelectedWall ())

Considerații

1. Obiectul operației (în exemplu peretele) nu este decis în momentul creării acțiunilor ci în momentul execuției.
2. Este posibil să încapsulați o acțiune astfel încât să fie atomică. Este astfel posibil să se implementeze o paradigmă bazată pe tranzacții în care un set de operațiuni este efectuat în totalitate sau deloc.
3. Comenzile , care sunt conștiente de operațiunile pe care sunt chemați să le efectueze, pot implementa funcții neexecutate sau anulate . În astfel de cazuri, Comanda poate stoca starea înainte de executarea acesteia, restaurând-o dacă operațiunea trebuie anulată.
4. Este posibil ca alegerea comenzilor să fie asincronă în ceea ce privește executarea lor. Un număr de comenzi pot fi consumate de un alt obiect care le primește la un moment diferit de cel al selecției lor.

Bibliografie

• Gamma, E. , Helm, R. , Johnson, R. și Vlissides, J. , Design Patterns : Elements for Object-Oriented Software Reuse , Addison Wesley, 1995, ISBN 88-7192-150-X .
  • Original: Design Patterns: Elements of Reusable Object-Oriented Software , Addison Wesley, 1995, ISBN 0-201-63361-2 .

Alte proiecte

• Wikimedia Commons conține imagini sau alte fișiere despre modelul de comandă

Portal IT : accesați intrările Wikipedia care se ocupă cu IT