Prev: design pattern - Chain-of-command
Next: Exposing contained types.. Especially LISTS
From: H. S. Lahman on 18 Dec 2007 10:36
Responding to Jo...

> hi there:
>
> the problem is the following, i have an application that needs to go
> and process something. my quesiton is:
> how do i actually show this progress?
>
> say we have the following procedure in a ui class
>
> public void ProcessSomething ()
> {
> foreach( string s in ListOfStrings)
> {
> ProcessEachLine(s);
> }
> }
>
> in a separate class you would actually have the ProcessEachLine(string
> s){...}
>
> however this aproach must be wrong because the ui class would have the
> responsibility for calling the processing of each line and it could
> introduce errors,
>
> so basically my quesiton is, how do you do this?, the dificulty comes
> because if you want to say, use a progress bar or somethign like that
> to show the progress you need to have some iteration, however in the
> iteration is basically where a bug can be introduced, say i need to
> add a different interface in the future, what if , the loop is
> designed in a difewrent way, then the result could be different. so I
> would appreciate your input.

The root problem is separation of concerns. The UI exists to communicate
with the user _in a convenient manner for the user_. That means that the
display paradigm is usually paramount when dealing with the UI. This for
a GUI one might have objects like Window and Control while for a browser
one might have objects like Page and Section. The UI subject matter is
basically to reformat messages to/from the user's display view from/to
the problem solution's view.

The main application lives to solve some problem for the user. That
application needs to abstract the problem space so one might have
objects like Customer and Account. The problem solution owns the logic
for actually doing something the user wants.

So one wants to separate those concerns and allow them to communicate
with messages. But each domain may have its own interpretation of the
message semantics. Thus the GUI may interpret the message as, "The user
clicked the Save button for the XYZ dialog with these field values."
Meanwhile the problem solution may interpret the message as, "Here is
the data for setting up a new Account."

If one thinks of the messages going back and forth as pure data
transfers one conceptually has a message composed of {message ID,
optional data packet}. All the UI and the problem solution need to share
is the mapping of any data packet in its own terms (e.g., window fields
vs. Account attributes) and a view of the message identity that is
consistent with the problem space (e.g., Save XYZ window contents =
create new account).

So now we are down to the user doing something in the UI and the UI
needs to announce that to the problem solution by sending a message to
the problem solution. As long as that message eventually gets to the
right object in the problem solution that has an appropriate response
(i.e., will do the right thing), all is well.

A remaining problem is granularity. In your example does one want to
send one message for each string in the listbox or does one want to send
a single message with all the strings? That will largely depend on what
the problem solution needs. One will tend to want the former when the
problem solution is constructed to treat each string as independent
while one will want the latter when the solution context regards the
aggregate of strings as something important.

In either case, though, you will be substantially down the road of
decoupling implementations if (A) you think of the messages as
announcements and data transfers and construct the relevant object
interfaces accordingly and (B) you make sure the UI does UI things
related to display with little knowledge of problem semantics while the
main application owns the behaviors that solve the problem in hand with
no knowledge of display paradigms.

Alas, the 3GL type systems introduce a great deal of physical coupling
when mapping to the hardware computational models. That can lead to
dependencies that make 3GL code difficult to maintain. In particular, in
the 3GL type systems messages are not separated from methods (i.e., the
message is the method signature). So to send a message the sender must
know entirely too much about the receiver; it must know a particular
receiver cares about the announcement, what behavior that receiver will
respond with (we name methods by what they do in the signature), and it
must know that behavior is the next thing to do in the overall problem
solution.

To remove that coupling one needs to resort to indirection. So we tend
to encapsulate different subject matters behind interfaces in
subsystems. The UI is clearly a very different subject matter than the
problem solution because we abstract it differently (Window/Control vs.
Customer/Account). So when the UI sends a message, it sends it to the
problem solution's subsystem interface rather than directly to the
object that will actually do the processing. Then it becomes a private
matter in the problem solution's interface to know how to re-dispatch
that message to the right object based on message identity.

As a bonus, one can use such interfaces to provide even more
sophisticated mappings. Thus in the UI it might be convenient to dump
all the strings when the user hits a particular button while in the
problem solution they might be processed independently. The problem
solution's subsystem interface can provide that sort of decoding by
splitting up the single incoming message into multiple messages within
the problem solution.

You might find the category on Application Partitioning on my blog of
interest; it goes into a lot more detail.


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

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



 | 
Pages: 1
Prev: design pattern - Chain-of-command
Next: Exposing contained types.. Especially LISTS