Michael Karlesky wrote:

> So, Model-View-Presenter translates to 'Business Logic'-'GUI
> Widgets'-'GUI Logic'. Separating business logic and presentation
> logic makes for cleaner, more flexible design and good testing.

That makes sense.

> We've found that in Agile fashion, stories map very, very well to
> Presenters. A customer usually talks about their actions in terms of
> a user interface.

I can understand that benefit to creating a Presenter in MVP.

> So, to answer your central question, the value of the Conductor in
> Model-Conductor-Hardware is that it allows the hardware control logic
> to be segregated from the business logic.

So do two separate modules, business and hardware.

> By testing the Conductor,
> hardware conditions and event handling (interrupts, etc.) can be
> tested apart from the data handling and number crunching logic of the
> Model.

So do two modules, with a test driver for each.

> Let me give you an example. Imagine an embedded system that processes
> temperature. The Hardware layer wraps the temperature sensor and the
> timer that triggers temperature reading (the wrapping is to make unit
> testing possible in the first place, of course). The Conductor
> handles timer events and asks the hardware for raw temperature
> values.

What I can imagine from your and Mr. Grenning's examples is that the two
interfaces, the MC and CH interfaces, are chosen such that
1. The MC interface is in terms of the natural core logic units and concepts,
somewhat independent of the particular hardware interface.
2. The CH interface is closely aligned to the particular hardware interface,
keeping the H layer thin.

With that scheme, the C layer can translate units (as suggested in Mr.
Grenning's
message), do hardware dependent sequencing, like your example of taking a
reading
when the timer expires, and probably isolating the core logic from at the lower
levels of timing service. One of the keys to that type of mapping, I think,
would
be determining the proper division between the core logic and the conductor,
since
it doesn't seem as obvious as the division between the model and the presenter
in
the MVP pattern: should input averaging be done in the C or M layer, for
example.

Am I getting warm?

As a suggestion to presentation, it helps me to see guidelines for drawing the
borders. Specifying an interface at some natural or logical level seems to me
to
be a key here. The example in the paper I read basically had a pass-through
wrapper for the conductor, as I recall, so it wasn't obvious what the benefit of
such a layer would be. I think a more complex example, showing the separation
of
the different abstractions at the two interfaces (and corresponding conductor
processing) would help me, as well as potentially others.

Thanks for the detailed response.

Thad