Stable Middle Man

StableMiddleMan is a different way of thinking about the PreserveWholeObject refactoring. It completely isolates the middle man from changes at either end, and does a good job of isolating both ends from each other.

The scenario:

You have three classes, A, B and C. A contains B, so C can only talk to A. A is a very stable class and you would like to keep it from changing as much as possible. B, however, is extremely volatile, for whatever reason, and C needs to perform various operations and A (or a collection of A's) based on the contents of B.

As an example, suppose you have a Person class that contains an Address object. For whatever reason, Person is utterly stable, but the number of fields in Address is constantly in flux, and every now and again its type changes (in CeePlusPlus, perhaps between std::string and char[80]). Now you have a Geography class that needs to calculate driving distances between two people.

What we want, then, is a way for C to talk to B without forcing A to change its interface every time B does.

If we don't care about creating a dependency directly between C and B, A can simply pass its B object directly to C.

 // in Geography
 Address1 = PersonA.GetAddress();
 Address2 = PersonB.GetAddress();
 CalculateDistance( Address1, Address2 );

This solution violates the LawOfDemeter, and suffers from the consequences one would expect thereof--changes to B affect C. In discussing this on the ExtremeProgramming mailing list, several solutions were proposed, all of which seem to fit into a common category: Creating a second, generic middleman.

This extra middle man serves to isolate C from B (and vice versa).

Let's call this middleman AddressQuery. (This conceptually ties the middleman to the Address class--perhaps a better distinction can be formed?) Now all we have to do is have Person pass the AddressQuery between Geography and Address. This middleman class closely matches the AdapterPattern as well.

Is there a better name for this pattern? "StableMiddleMan" is basically the motivation, but the pattern that emerges is a different concept. GenericAdapter?? AddMiddleMan?? ParallelMiddleMan?? MiddleManBlithelyUnawareOfAdapterDetails??

(last edited March 9, 2001)

AnswerMe: Can somebody give an example what this AddressQuery would look like in the above case?

I'll take a shot at it. The AddressQuery would only contain those address fields that are of interest to the Geography class in making its calculation. If Geography only cares to make rough estimates of distance in the USA, then there might only be a single field: PostalCode. It is Addresses responsibility to fill in the AddressQuery to the best of its ability.

What's wrong with:

 address1 = personA.getAddress();
 address2 = personB.getAddress();
 d = address1.milesTo(address2);

hiding any changes to Address behind the milesTo method. -- mt

CategoryPattern