Re: Client/Service Design Style.

Hi John,

JC> The idea is whenever you have any two interacting modules / objects
JC> you explicit elect one to be the client and the other the service.

I consider this "layering". You can call down into lower layers, but
not back up to higher ones (unless you pass in a callback of some
kind).

JC> What I'm talking about is a style of design, OOD or otherwise where
JC> the software is partitioned into modules every interacting pair of
JC> modules is either a client or a service.

This is "partitioning", but might also just be considered "modularity".

JC> The client is written so that it is bound to the interface of the
JC> service but utterly ignorant of the implementation.

JC> The service is written to encapsulate it's state in a manner that it
JC> cannot unwittingly be corrupted by any client.

This is "information hiding".

All of these fall under the auspices of modular programming. They have
each had new names and and refinements applied in different
areas, e.g., information hiding is "encapsulation" in OO terms.

Do you want references to the original ideas, or current ref's
specific to a toolset or language?

--Gregg