Client/Service Design Style.

This is such an old idea, such an obvious notion, yet a Good One. All
my own code is written in this manner and it produces such elegant
designs it surely must be a standard practice...

Yet I can't put my googly fingers on any good references.... maybe
it's known by some other name?

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

The term Client/ Server seems to have been appropriated to mean only a
form of distributed computing.

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

There is no requirement that the client be on a different device or
even in a different process or thread to the service.

A service may be a client of other services, provided the dependency
graph doesn't contain cycles.

But the interface to the service is written so that the service is in
no way bound a particular client.

In fact one or more other modules or indeed one or more instances of a
client may use that service.

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

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

Any references?



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : [email protected]
New Zealand