Frage

According to the GoF Command Pattern UML it seems to me like ConcreteCommand just adapts Reciever to common Command (which could be) interface. I am probably hit by golden hammer, so please explain where is the difference or what did I get wrong.

Command pattern

War es hilfreich?

Lösung

A lot of these patterns do look very similar and intent does help in understanding the pattern definition. Here is my (probably incomplete) knowledge on these patterns:

The Command pattern seperates the invoker from the operation.

A Command may have a lifetime independent of a specific request, receiver, or invoker - it is a seperate first-class entity. It allows the ability for queuing, and executing commands at different times and allows command execution to be recorded/remembered, perhaps for logging.

It can be used to organise UI command implementation, undo, or redo functionality,or transaction management as examples.

The Adapter pattern is used to adapt an object to the usage of another.

I wouldn't confuse an object that operates on another object (ConcreteCommand doing something to Receiver) with an implementation of the 'Adaptor' pattern where an Adaptor acts almost like a proxy to allow the Adaptee to work with other collaborators.

Andere Tipps

The two are essentially different. Let me explain why :

You cannot travel from one place to another by airplane without using the command pattern!

If you are a frequent traveler, all you care about as a client is to travel from where you are to another . you don't care about how the pilot will fly the plane or which airline will be available .. you cant really predict that. all you want is to get the the air port and tell them to take you to your destination. But if you do that, your command to the airport authorities will be laughed at! they need you to supply a command object, which is your ticket. as much as you don't care about which airline or which plane type, when you are ready to fly, you need to supply a ticket command object. The invoker, which is the airport officials needs to check your command (ticket) so that they can validate it, undo it if it is fake, redo it if they made a mistake (without you having to go through the booking process all over). In short , they want to have complete control of your command (ticket) before deciding whether or not to invoke or execute your command, which lets the airline (the receiver ) execute ( put you on a plane and take you to your destination) . Mind you, your command (your ticket) already has the information of the receiver (airline) without which the airport officials wont even start to process your ticket in the first place.

The airport authorities could even have a bunch of tickets they are working on. they may choose to delay my ticket and let someone that came after me go through (invoke another persons ticket before mine)

You cannot trade as usual without using the adapter pattern!

some time past, the major means of trade was by batter: If you want my laptop, give me your desktop and TV. The problem was that you may not have what i want so we cant trade. the solution was adapter pattern. we couldn't trade because we have incompatible interfaces (wants). so money was invented. So now if you want my laptop, go through the adapter, pawn it and get some money. Yeah! I definitely want some money. Almost every one implements the abstract class called Money (or IMoney of which Dollars is an instance). Do you? Now in contrast to Command pattern, money has no information about receiver on it. I wish money was a command object with me as a receiver. That will be so cool. But no! while a ticket can to be invoked, undone or redone, etc, money is always accepted. If you give me some, I will do one thing: Accept it.

In Command pattern, command objects know the guy, who is able to complete the given request. or It may also knows who are all the guys needed, to complete the request. (For ex: if the request is "Do washing", Command object gets the clothes, find the washing machine, puts the detergent, swirl the machine and completes the process. For these actions, It can call other guys (objects).

In Adapter pattern, the adapter doesn't know the guy, who is able complete the job. It also doesn't know anything about the request or how to get the job done. All it does is to invoke another guy who has implemented the non-compatible interface.

adapter either is-a or has-a adaptee. the concrete command has-a receiver. so the arrow goes the in the other direction.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top