Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Chain of Command vs. Mediator

Chain of Command vs. Mediator

Chain of Command vs. Mediator

I could use some help with the model for our lab's measurement software.  I'm an electrical engineer most of the time but I am also the software developer since we are small and I'm the most qualified.  I have migrated our code from VB6 to VB.NET and finally to C# after learning generics with C# examples and became tired of VB syntax.  I've read books on design patterns and but it's still a bit ambigous to me.

In a nutshell, the software basically talks to a device which performs a measurement on a widget, and then exports the results.  Most often, another device(s) will 'perturb' the setup for additional measurements.  We have a variety of measuring devices, perturbing devices, and exporting targets. The original software was procedural with a heavy GUI.  It severely lacked reusability and extensibility becase each device had unique capabilities.

After analyzing the trends,  I narrowed the model down to four primary classes: Measurement, MetrologyDevice, Permuter, and Exporter.  Each device could be configured before the measurement and a handful of required properties/methods could be handled through a common interface.  PropertyGrids are used for everything, so the code for the GUI is inside each class as a TypeDescriptor/TypeConverter and not tied to a specific GUI.  Here's a list of the primary classes and their interfaces:

Exporter    -Takes data and exports it to a file, UI, another app, or database, etc.

Permuter    -Implements a change to be measured.  An example of a Permuter is a motion control axis or a furnace temperature controller.
    event StatusUpdate(status) (Waiting, Done, Finished, Error)(Done signifies a completed a permutation while finished signifies it has completed all of its permutations defined by start/stop/step or a list of values)

MetrologyDevice    -Performs the measurement which generates a dataset to be stored. Spectrum analyzer, digital I/O, A/D, variety of electronic gauges, etc.
    event StatusUpdate(status)    (Waiting, Done, Error)

Measurement  -Primary interface between user/gui & devices.  Implementation of either 'chain of responsibility' or 'mediator'
    event StatusUpdate(status) (Ready, Measuring, Done, Error)
    List(of IMetrologyDevice)
    List(of IPermuter)
        List(of IExporter)

There can be any number of Permuters, typically a combination of others in parallel and serial.  I currently have the model using a mediator, PermuterMaster, which governs when each permuter should DoSomething().  It would poll each Permuter to see if it's done, tell the MetrologyDevice to measure, get the data, and send it to the Export object.  

As an alternative, I could implement a chain of command, where the Measurement class sets up event delegations so that each object notifies the appropiate peer/parent.  A permuter would tell the parent permuter it's done, which would then tell the MetrologyDevice it's done, which would send the data to the Exporter, which would tell the Permuters to permute again.  Both methods will work fine but I can't figure out which is best.  I'm leaning towards chain of command the more I think about it.  As I look at what I just typed above, I also noticed that IPermuter and IMetrologyDevice only differ in the fact that IPermuter has one extra status, 'completely done'.  Would combining both be logical?  Any insight would be greatly appreciated! glasses


RE: Chain of Command vs. Mediator


It severely lacked reusability and extensibility because each device had unique capabilities.
extensibility: YES!
reusability: no. OOP is about encapsulating the details of how something works and reducing the effects of change. Udi Dahan has a great post* about this.


I also noticed that IPermuter and IMetrologyDevice only differ in the fact that IPermuter has one extra status, 'completely done'.  Would combining both be logical?
unless IMetrologyDevice is a conceptual extension of IPermuter, no, it's not wise to inherit (or combine) one with the other.


Both methods will work fine but I can't figure out which is best.
the one that is easier to implement yet still meets your requirements.

Other than that it's still early in the morning and I'm lacking coffee :) There may be other insights we could provide, but for now that's all I got.
*I tried the url this morning around 8:45, but his site was down. this isn't typical of his site, so if you get a 503 error try again later on.

Jason Meckley

FAQ855-7190: Database Connection Management
FAQ732-7259: Keeping the UI responsive

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close