Split CompositeCommand into two classes

Topics: Prism v4 - WPF 4
Nov 10, 2011 at 3:55 PM

Currently, CompositeCommand does two things: 

1) Provide an implementation of the Composite pattern for an ICommand.

2) Listen to an IActiveAware-implementing command's IsActiveChanged event, firing each CanExecuteChanged event as a result.

These are two separate concerns, with the latter best separated as a decorator that commands can optionally use. 

In addition, this decorator should not require the wrapped ICommand to implement IActiveAware, it should accept a separate IActiveAware argument, so as not to violate the Liskov substition principle.

Nov 10, 2011 at 6:14 PM


Based on my understanding implementing the IActiveAware in the underlying ICommands registered with CompositeCommand, is done to support scenarios where you need to define which child commands will be used. Hence the CompositeCommand class will consider each child command's active status when determining the return value for the CanExecute method and when executing child commands within the Execute method. This behavior is only present if the monitorCommandActivity parameter is true.

The IsActiveChanged event does not raise the CanExecute method. This is done in the RaiseCanExecuteChanged method.

Therefore, the design decision to place this logic (the logic for deciding which command's CanExecute value to take into account depending on its ActiveAware state) in the same place as the general CompositeCommand logic seems to account for the fact that both define the working of the CompositeCommand, which in my opinion wouldn't be complete if only one of them was present.

If you anyway think this should be modified in Prism you could create a work item in the Issue Tracker so the p&p analizes it for future releases.


Agustin Adami