Re: Auto selection

Responding to Tailorma_de...

If the interface is message-based, one gets a lot of decoupling because
each side can map the message and its data packet to its own view of the


You say 'message-based'. Does this really mean to solely communicate
with (Integer-)IDs? No other parameters? There are no references passed
anymore? Sorry for getting non-abstract. But I cannot imagine how this
should be realized in code. And would this also mean that the business
model has to manage state things?

A message-based interface is based on {message ID, <data packet>}. It is a pure data-transfer interface. Ideally the data packet contains data by value, which provides <almost> complete decoupling of the sender and receiver context semantics (i.e., all either share is an understanding of the message itself). Passing data by reference exposes the sender implementation and opens the potential for the receiver to change it in unexpected ways.

Event-based interfaces are the most general form of message-based interfaces because the message ID can be expressed in terms of data rather than behavior (i.e., a procedural call). That allows support of asynchronous communications.

Note that in event-based interfaces there is no need to send data by reference. That's because there is no return when an event is generated since there could be an arbitrary delay between when an event is generated and when it is consumed by the receiver in asynchronous communications (e.g., distributed). Thus any values returned by the receiver are sent back in a separate event data packet where the sender/receiver roles are reversed.

<Caveat>
At the 3GL level it is a common optimization for the sender to provide references to data that the receiver needs to provide. That dates back to the earliest 3GL days because all the 3GLs, including OOPLs, are all inherently synchronous since they employ procedural message passing. (So to do true asynchronous processing at the 3GL level, one has to introduce artificial supporting infrastructures, such as threads and serialization through event queues.)

Obviously one can optimize performance at the 3GL level by taking advantage of "free" procedural message passing to eliminate multiple "handshaking" communications and the encode/decode of data packets. That is done routinely within subsystems because those objects are already carnally related through the subsystem subject matter and the overhead of decoupling at the object level would often be prohibitive. However, at the subsystem or layer level, the overhead is proportionately much less and the differences in subject matter abstraction can be profound across the boundary. So at that level using a pure message-based interface is almost always justified.
</Caveat>


Consider my example scenario within my other started thread
http://groups.google.at/group/comp.object/browse_frm/thread/ec3ab177baad669a/#
: The command CloseProject. When it gets triggered e.g. by a menu entry
then it could be that some files should be saved. That requires user
interaction. A dialog would get visisble where the user chooses which
file to save before the project get closed. Would a click on okay send
one single ID to the BM which interprets this as a 'Save those files
that were recently marked as must-be-saved in the save-files-dialog?
Would this mean that selection becomes part of the BM? I guess not,
right?

Note that the GoF pattern examples essentially deal with this case _within the GUI subsystem context_ (i.e., the Open Command example at the bottom of p. 234 in the Motivation section).

Are there other, alternative interface communication models, beside the
message-based one?

I think the point that I and others are making is that the Command pattern is not an interface issue. It is likely to be relevant /within/ a GUI subsystem or /within/ the business solution, but not in the interfaces between those subsystems. IOW, the 'interface' the pattern is talking about is not the subsystem interface; it is an artificial interface created to simplify communications between a client object and a service object that depend on dynamic context.

The basic problem that the Command pattern is solving is:

[Client]
| 1
|
| R1
|
| invokes
| 1
[Receiver]

The difficulty lies in a difference in level of abstraction between the [Client] and the [Receiver]. The [Client] wants the [Receiver] to provide some <in its view> basic service. But what the [Receiver] actually needs to do to provide that service depends upon dynamic context and may require multiple activities _at the [Receiver] level of abstraction_. IOW, what the [Receiver] actually needs to do in response to the [Client] request depends upon the run-time dynamic context.

More specifically, in the situations where Command is applicable, [Client] understands the context (i.e., which [ConcreteCommand] is appropriate) but it doesn't understand the details of what needs to be done _in that context_. That dynamic complexity is far too complicated to capture is some simple static association like R1.

The answer to this problem is to separate the concerns of context from those of invocation. One delegates and encapsulates the details of the invocation to a suite of [ContreteCommand] objects. One then has [Client] assign the correct "receiver" relationship for the context. FInally [Client] employs polymorphic dispatch to actually access the detailed invocation without knowing anything specific about it.

However, this all happens /within/ one of the subsystems and the 'interface' is just the abstract interface provided by [Command] for the polymorphic dispatch. At the most the subsystem interface will instantiate the "receiver" relationship based on the message it receives and will dispatch to Command.execute(). IOW, at most the subsystem interface is playing the role of [Client] in the pattern. So...


In my (semi-prof.) application I have realized the command pattern that
way so the UI can instantiate command object and add them to the
executing unit (invoker). So it is part of the business model API.

This is what we are pushing back about. You may have a Command pattern in the GUI that invokes a dialog box as one of the activities needed to service a request _within the GUI_. You may have a Command pattern in the business logic to handle some analogous dynamic relationship problem. But those applications of the design pattern will be completely orthogonal. And...

Those command objects are parameterized with some references of
business model objects which are kept in UI objects, e.g. with a tag
property of a tree node. The command SaveProject would be started this
way:
ExecUnit.Execute(new SaveProject(p)) where p is reference to a BM
project object.

The real issue here is: Don't Do That! B-)

There is no reason for the GUI subsystem, that is using the Command pattern to manipulate a bunch of windows and controls, to know anything about what a project is. The GUI just displays a bunch of data the business logic or the user gives it. That pile of data may happen to map exactly to the attributes of a [Project] object on the business side, but the GUI subsystem should not know that.

For example, let's assume the user is making selections from menus and stuff while providing basic form-based data entry. Because of the complexity of the forms, one may need the user to fill in some of that data through popup dialogs. That complexity might warrant the use of the Command pattern _during the data entry_. But once the data entry is done, the problem solution needs to be informed. The problem solution doesn't care how the data was entered; it just needs the data. At that point the GUI cobbles together a data packet from the various controls and whatnot and sends it off to the business logic via {saveWindow3, <data packet>}.

The price of this decoupling is that one needs encode/decode of message data packets on both sides. That's because each subsystem has entirely different views of the message semantics (Window/Control for the GUI vs. Project for the business logic). However, that price is well worth it precisely because each subsystem /can/ have its own unique view of what the message semantics is. That allows one to hand tailor each subsystem's abstractions to the specific subject matter. In turn, that allows one to capture unique invariants in the subsystems that will simplify those subsystems. But most important, it hides the implementations. For example, one can swap a browser-based UI for the GUI without the interface that the business logic sees changing at all.

Note that passing a reference to a Project across the interface is purely a matter of coupling. It exposes the implementation of the business logic subsystem to the GUI subsystem. A subsystem can be viewed as an object on steroids. The same OO notions like implementation hiding apply to subsystems that apply to individual objects. So one seeks to eliminate that level of coupling between subsystems.

However, that decoupling issue is unrelated to the sorts of dynamic contexts that drive the use of the Command pattern /within/ subsystems.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Beginner Question: Windows Object Oriented Coding Hierarchy
    ... Each subject matter is ... If the subsystem interface is a pure by-value data ... So when the banking subsystem sends the GUI subsystem a message ...
    (comp.object)
  • Re: LSP violation or not
    ... why IntegerInput needs to the implemented "in terms of" TextInput. ... The GUI justification seems to support this view. ... In that situation each subsystem abstracts the ... problem solution interface know to convert the text string to an integer? ...
    (comp.object)
  • Re: UI subsystem interface design
    ... Typically a Window instance in the subsystem will ... mapping object in the context of this interface is a endomorphism ... The idea is that the mappings can be used so that a complex GUI can ...
    (comp.object)
  • Re: Restricting functionality on objects: "remote access proxy" (pattern)
    ... about the current user's access rights in a chat. ... If the level of privilege can change during the chat, then whoever understands that change context can simply reset the privilege attribute value. ... The simplest implementation is for the subsystem interface to re-dispatch those messages to objects that have the responsibilities needed to to service the user's request. ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > If the clock service has identity then the client looks like... ... The first line exists in the server. ... external interface is the traditional input interface whose ...
    (comp.object)