jQuery in Action, 2nd edition*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Adapter or Mediator? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Adapter or Mediator?" Watch "Adapter or Mediator?" New topic
Author

Adapter or Mediator?

Sun Raj
Greenhorn

Joined: Mar 09, 2005
Posts: 11
I have the following situation:
There is a tax info interface.
Different states implement this interface.
There about 50 classes that implement this interface.
The new requirement is to implement a class that instantiates one or more of these
(based on some settings) and display tax information of each of the selected states.

Will this be called a mediator pattern or an adapter pattern?

The reason I have this doubt is that like Mediator the new class mediates on behalf of the client and
the colleague classes. It does add new functionality.
But unlike classic definition of Mediator does not have a separate interface but does implement the same
interface as the colleague. The constructor takes a list of selected states.

The reason I think is an adapter is that it is one more implementation of the interface by adapting the user
data to call various objects and collecting and formatting the output from various objects
so that the user sees it as one unit.



TIA

SR
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Sounds like a Composite to me.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Sun Raj
Greenhorn

Joined: Mar 09, 2005
Posts: 11
Ilja,
I don't think it is a Composite. The class here knows about the colleague classes but does not contain instances of the ccolleague classes.
Based on the selection just invokes methods (described on the interface) on the colleague objects.

-SN
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Sun Raj:
The class here knows about the colleague classes but does not contain instances of the ccolleague classes.


I don't understand what you are getting at here? What do you mean by "knows about"?
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1007
    
    3
Originally posted by Sun Raj:
I have the following situation:
There is a tax info interface.
Different states implement this interface.
There about 50 classes that implement this interface.
The new requirement is to implement a class that instantiates one or more of these
(based on some settings) and display tax information of each of the selected states.

Will this be called a mediator pattern or an adapter pattern?

The reason I have this doubt is that like Mediator the new class mediates on behalf of the client and
the colleague classes. It does add new functionality.
But unlike classic definition of Mediator does not have a separate interface but does implement the same
interface as the colleague. The constructor takes a list of selected states.

The reason I think is an adapter is that it is one more implementation of the interface by adapting the user
data to call various objects and collecting and formatting the output from various objects
so that the user sees it as one unit.



I wouldn't call it either a Mediator or Adapter pattern. You aren't encapsulating how the client object interacts with the various possible concrete implementations of the interface. In fact, once a particular implementation is instantiated, there's no intermediary object between the client object and the concrete TaxInfo implementors, so I wouldn't call it either a Structural or Behavioral pattern (to use the GoF parlance) at all.

I would say what you do have is a Factory. If I understand correctly, you have a class that takes the state name as an argument and returns either an AlabamaTaxInfo obj, or an AlaskaTaxInfo obj, etc.

Just a plain old Factory is a simplification of what the GoF have defined as an Abstract Factory. If you have a copy of "Design Patterns" look at Structure section for Abstract Factory (page 87?). Instead of a hierarchy of factories, you define the factory interface and implement it in a single class. As for the products, you'd have only one tree in that section of the diagram: the TaxInfo interface and fifty concrete "products" that implement the interface.

Could you say you're using the Factory Method pattern? I'd say no. As it's described in the GoF book, the client objects form a class hierarchy with each subclass isntantiating the ConcreteProduct that's appropriate. With the Factory Method pattern the client class picks the ConcreteProduct at program time, whereas you're client is picking the concrete TaxInfo implementor based on user input at run time. That's not what you have. You have one client class that remains blissfully ignorant of what TaxInfo implementor will handle the calculateTax() request.

Reasonable?

Ryan
[ March 21, 2005: Message edited by: Ryan McGuire ]
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1007
    
    3
As for naming the "pattern" the that fifty concrete TaxInfo classes implement... it's just plain old Interface Implementation. Once the correct concrete TaxInfo object(s) is/are instantiated. There's nothing special about having each one implement the method(s) defined in the TaxInfo interface differently. That's how polymorphism, one of the cornerstones of OOD/P, is defined.

Ryan
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1007
    
    3
Originally posted by Ryan McGuire:

I wouldn't call it either a Mediator or Adapter pattern. You aren't encapsulating how the client object interacts with the various possible concrete implementations of the interface. In fact, once a particular implementation is instantiated, there's no intermediary object between the client object and the concrete TaxInfo implementors, so I wouldn't call it either a Structural or Behavioral pattern (to use the GoF parlance) at all. ...


Wait, I take it back. Now that I've reread your original question, I see that you DO have a new intermediary between the ultimate client and the concrete TaxInfo implementors. If this new object implements TaxInfo but just delegates the actual calculateTaxAmount() calls to the other objects, then I would agree with Ilja and say it's a Composite that just happens to be restricted to one layer of containment in practice.

An argument could be made that you're implementing the Facade pattern. You have one object that simplifies the interface to bunch of others. Usually, however, a Facade simplifies the interface to a bunch of heterogeneous objects instead just an array of object that all implement the same interface.


I don't think it is a Composite. The class here knows about the colleague classes but does not contain instances of the ccolleague classes.


First off, what do you mean by "does not contain"? The TaxInfoCoordinataor must have a reference to any of the other TaxInfo objects it needs to use. "Has a reference to" is pretty much synonymous with "contains", depending on how far you want to stretch the term.

Are you saying that this new TaxInfoCoordinator object doesn't instantiate and contain the individual OhioTaxInfo, NewJerseyTaxInfo, etc. objects, even though those might have a lifetime of only the duration of the calculateTaxAmount() call? That doesn't mean you don't have Composite or Facade pattern; it's just a non-standard instance of it.

Or are you saying that there are already instances of the fifty state-specific TaxInfo classes before this new TaxInfoCoordinator is instantiated and used (and perhaps destroyed)? That's still within the realms of the Composite and Facade patterns. Additionally, you may be using other patterns to maintain this pool of fifty individual TaxInfo objects. They could considered Flyweights, depending whether they store any state information.

In both of these cases where the higher level coordinator doesn't have the same lifetime as the lower level individual TaxInfo implementors, the structure of the Composite or Facade pattern is short lived, but it still is a case of the pattern for that short time.

Ryan "grind it into the ground" McGuire
[ March 22, 2005: Message edited by: Ryan McGuire ]
Sun Raj
Greenhorn

Joined: Mar 09, 2005
Posts: 11
Ryan,
Thanks for your reply.

The construction and lifecycle management of the individual state tax info objects is managed elsewhere in the application. The new class that was added does the following:
Based on the a state(s) selection, for each selected state (which it gets from some other part of the application), it interacts with a factory object to get the corresponding state tax info object and runs the getInfo method on the taxinfo object and collects the returned value(in this case pdf byte[])
Finally it reutrns the pdf output (with some formatting such as page numbering etc.) of the tax info of all the selected states.

Please clarify the following:
Are Composite and Mediator/Adapter mutually exclusive?

Thanks.
-SR
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1007
    
    3
Originally posted by Sun Raj:
Ryan,
Thanks for your reply.
...
Please clarify the following:
Are Composite and Mediator/Adapter mutually exclusive?


Of course you can use some combination of patterns in a solution to a problem, so use of one doesn't preclude use of others. I bet you knew that, so I assume you're asking if a single class or object can be identified as only one of the above, right?

No. You could have a single class that acts as both an Adapter and a Composite. In fact, I could easily see how one object could be both a Mediator and a Facade at the same time if the designers originally had the intent of using this one object to clean up/decouple interactions between the objects making up a subsystem (Mediator) and the interface that the subsystem presents to client objects (Facade).

Even though many standard design patterns have the same class and/or object diagrams, it is their intents or the problems that they're solving that determine what pattern is being implemented. I could go into some examples, but it would probably be just as easy if you read the Intent sections for the various patterns.

I hope this helps.

Ryan
Robert Hayes
Ranch Hand

Joined: Oct 24, 2004
Posts: 116
A good example of what Ryan is talking about (ie: intent) would be Adapter vs Decorator vs Facade.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Robert Hayes:
A good example of what Ryan is talking about (ie: intent) would be Adapter vs Decorator vs Facade.


Well, I actually think that those three also differ significantly in implementation: a Decorator has the same interface as the object it decorates, an Adapter has a different one. A Facade typically delegates to more than one object (in contrast to Decorator and Adapter).

A better example might be Decorator vs. Proxy or Strategy vs. State.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
We get Books 24x7 as a perk at work, and I was just browsing a Holub book on OO patterns. He points out that many of the GoF patterns have (nearly) identical static diagrams - some interfaces, some implementations, yadda yadda. The intent and the dynamic usage are subtly different, tho. I'm good with Ilja's categories.

BTW: He had a nice take on "what is OO" and "what is more or less OO". The language has little to do with it ... the DESIGN is OO or not. After all, real programmers can write Fortran in any langauge. And of course we know the controversy around his ideas about OO design.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1007
    
    3
Originally posted by Ilja Preuss:

A better example might be Decorator vs. Proxy or Strategy vs. State.


Along with Decorator and Proxy, I would add Composite. Even though a Composite implements the same interface as the leaf nodes, it differs from a Decorator or Proxy in that a Composite is usually designed to reference 1..* others, whereas Decorators and Proxies usually reference just 1 (or maybe 0..1) others.

...and that's why the answer to the original question in this thread is "Composite".

Ryan
[ March 29, 2005: Message edited by: Ryan McGuire ]
 
jQuery in Action, 2nd edition
 
subject: Adapter or Mediator?