Open FredericChow00 opened 1 year ago
I don't see why it would be common for them to come together.
Since the Observable would be able to update the Observers without knowing the type of Observers
Seems like what you're describing is just polymorphism. Just because a design pattern uses polymorphism does not mean it uses the Command pattern.
Perhaps what you're confused about is that a portion of the Command design pattern kind of looks like the Observable design pattern.
Design patterns are defined by the problem they are trying to solve and a common generalised high-level solution for solving them. When viewed from a high-level, the Observer and Command pattern may appear to have similar solutions (similar to a certain extent that is), but when actually implemented, their implementations can be very different. This is because they are trying to solve very different problems.
Although the UML class diagram looks similar, their actual implementation can be very different as they are meant to solve different problems. The following are ways to implement the Command and Observer pattern which conform to their respective patterns but differ from one another:
In the case of the Command pattern, a Command
is given to the Invoker
. The Invoker
executes the Command
and that's that. The relationship between the Invoker
and the Command
ends there.
In the case of the Observer pattern, an Observer
subscribes to the Observable
for a specific event. Anytime the event takes place, the Observer
is notified by the Observable
. The Observer
remains subscribe until it decides to unsubscribe (or the program exits).
Can I have an implementation of the Observer pattern that is also a Command pattern? Probably. Design patterns don't have fix implementations. I would assume developers often have to adapt the pattern to fit their needs and thus come up with their own appropriate implementation.
@hingen got it thanks so much for the detailed response!
I would just like to add on @hingen response. I believe many complex applications require various patterns to handle different things. So, I would say that while the command pattern and observable are two different things, it often works hand in hand in applications.
For example, the observable pattern has an Observer
that subscribes to the Observable
to notify changes (for example some pricing change for a food ordering application.) Then, the command pattern will be invoked by the user (because he / she is informed of the new prices, so he might want to purchase something at a lower price.)
So, although they might serve two different purposes, I personally feel that many applications have both that come together. Just my two cents @FredericChow00!
Good discussion so for. Thanks for good inputs @hingen @ARPspoofing
- In the case of the Command pattern, a
Command
is given to theInvoker
. TheInvoker
executes theCommand
and that's that. The relationship between theInvoker
and theCommand
ends there.
Typically, yes. But it is possible that the invoker keeps the Command
object for a longer period, for example, if it has an undo feature.
Seems like what you're describing is just polymorphism. Just because a design pattern uses polymorphism does not mean it uses the Command pattern.
Yes, the solution part of both these patterns typically use Polymorphism and they both manage to decouple one part of the code from another. But the two patterns address two different problems.
More inputs on compare/contrast the two patterns are welcome.
@hingen @ARPspoofing @damithc thanks so much for the clarifications so far!
Can I check if Observer Patterns normally come together with Command Patterns? Since the Observable would be able to update the Observers without knowing the type of Observers