Re: software architecture/design question

Responding to Ragu...

I am relatively new to OO design. When I read the original post I
thought this pattern might be suitable. I believe the above design
looks similar to mediator pattern, where the SlotController is the
Mediator for the processor Collegues (A..G).

That is a possibility but I am skeptical (without further knowledge of the OP's actual problem).

Mediator is usually relevant when the relationships and/or collaborations can be arbitrary from one context to another. IOW, when one is providing reusable modules or the problem space intrinsically provides rather arbitrary relationships.

For example, the GoF example with GUI controls works nicely if one is providing a generic GUI subsystem to be used across applications. One will instantiate particular Control objects for each GUI context and those objects will have arbitrary relationships. The Mediator allows those relationships to be uniquely "registered" for each context without changing the code based on startup factory initialization from an external configuration file (e.g., a Windows resource file). However, Mediator would be overkill if one were designing a custom GUI for a single application, as in:

+------------------+
| |
1 R1 * | 0..* | R2
[Window] ---------------- [Control] -------------+
A 0..*
| R3
+-------+----...
| |
[TextBox] [RadioButton]

Participation in the relationship that R2 represents could be arbitrary across different GUI context and that could be managed by Mediator. But for a simple, unique GUI one can probably just "hard-wire" the relationship instantiation in a factory object based on the problem needs described in a configuration file. When a [Control] instance changes, it just notifies /any/ objects that are actually related to it and those objects do the appropriate thing for the change.

In this case I think the problem is somewhat simpler in that there seems to be a single application that enforces a single set of rules for the sequence of configuring the slots. Also, the sequencing rules don't seem very complicated and the participating slots are fixed so they can be readily captured in an ordered collection class for a relationship. IOW, there is nothing arbitrary about the sequence in any given execution of the application.

[Note that almost all of the GoF patterns are focused on a single, very general problem. One has a relationship in the problem space whose participation is too dynamically complex to express as a simple association. The GoF patterns then employ delegation and polymorphis dispatch to resolve the complexity for various specific sorts of realtionship management. R2 is an example of this. If participation in R2 is straight forward, all one needs is a pointer to a collection class that is allowed to be empty. If it is not so straight forward, then one needs something like Mediator or Observer to manage the dynamics of the relationship.]

In addition, I am suspicious that there is a lot more complex processing going on (e.g., the PCI translation) that are more important than just the configuration. To separate those concerns I would be inclined to used application partitioning to isolate subject matters. Then the subsystem interfaces provide the decoupling and the Facade pattern is more relevant because much of Mediator's work is a fait accompli since of the subsystems' isolation of subject matter, level of abstraction, and allocation of requirements.

[OTOH, if it turns out the subsystems are trivial, then it is easy to coalesce simple subsystems into a single subsystem later. At that point Mediator might become relevant for the relationship to [SlotCard] at the object level. But it is much tougher to split up existing subsystems so it is usually best to assume multiple subsystems up front.]


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Quantcast