• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Adapter or Mediator?

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sounds like a Composite to me.
 
Sun Raj
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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"?
 
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A good example of what Ryan is talking about (ie: intent) would be Adapter vs Decorator vs Facade.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ryan McGuire
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
I just had the craziest dream. This tiny ad was in it.
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic