2

According to Wikipedia:

In object-oriented programming, the command pattern is a behavioral design pattern in which an object is used to encapsulate all information needed to perform an action or trigger an event at a later time. This information includes the method name, the object that owns the method and values for the method parameters.

And according to professor Schmidt's text, a command has:

  • Time-independent execution of application logic. The encapsulation of application logic allows to queue it and execute it at a different point in time.
  • Context-independent execution of the application logic. The separation between application logic and context allows to execute the application in separate contexts, such as in a different thread or using a different state.
  • Exchangeability of application logic. The separation between application logic and context allows to easier exchange the application logic.

If you encapsulate all information into an Intent, the onHandleIntent works as an abstract method to the command executor, just like described at command processor pattern text.

Thus, instead of explicitly implement the executor in order to invoke a command, you simply delegate command execution to the operating system.

So the questions are:

  1. Is IntentService the framework implementation for command pattern?
  2. In affirmative case, why some Android MVP implementations explicitly implements its own, using ThreadExecutor as consumer and Runnable as commands, instead of using the one provided by the framework?
1

I would argue IntentService is not a framework implementation of the command-executor design pattern, because it does not meet the requirement of the separation of application logic and application context.

The command-executor pattern is like providing a button on a remote control to replay some action(s) on-demand (dim the lights, close curtains, turn on Barry Manilow) no matter who presses it in whatever context. Command-executor is analogous to materialising a personal assistant who then does a bunch of predetermined tasks for you on-demand.

On the other hand, the use of the IntentService class is analogous to a pedestrian hailing a taxi cab or a pub patron flagging the bartender: The agent requests a service (expresses an intent), the agent enters a queue to receive the service, the agent finally receives the service. Unlike the command-executor, this sequence requires the participation of the agent, which itself requires that the agent be in the right kind of context to (want to) receive the service. But this is not what the command-executor pattern prescribes. Indeed, the API class overview for IntentService in the link you provided suggests that the IntentService class fits another established design pattern:

This "work queue processor" pattern is commonly used to offload tasks from an application's main thread. The IntentService class exists to simplify this pattern and take care of the mechanics. To use it, extend IntentService and implement onHandleIntent(Intent). IntentService will receive the Intents, launch a worker thread, and stop the service as appropriate.

In a sense, the IntentService could be considered a command-executor if only the subject of the service could also be included in the abstraction. So for our analogies, if at any time we wished, we could invoke a command to "send my niece Suzy the birthday present I bought her" or "send me to Beijing to complete the business merger", then IntentService might be a command-executor. But when we state the comparison this way, it becomes clear IntentService could not be command-executor, because these events are dependent on context in the sense that they need objects or agents' participations prior to being able to run. This is not true for command-executors, which package all the necessary components for ready replay at any time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.