• 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

Problem applying factory method pattern

 
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am attempting to use the Factory method pattern. Classes B, C, and D are all children of an abstract class A. Each child has its own unique methods. Users have access to only the abstract class. I think it's not a good idea to give users the abstract class and ask them to cast back to the concrete class.
For instance,
A a = new C();
...
...
C c = (C) A;
c.uniqueMethod();
It would be nice when users invoke just the method on abstract class A. Unfortunately, B,C,and D do not contain common methods to be pushed up to class A.
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi there,

If B, C, and D don't have any methods in common, there is no reason to have them subclass A. Nor is there any benefit from subclassing A. You can still use the factory pattern if you want, just either:


a) have the factory method return an Object. This way you will always have to cast to the correct class though.

b) have a factory method for each class instead.


Perhaps a factory isn't even the best solution in this case... it depends on what you are trying to achieve.
 
Joe Nguyen
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They do have common methods.

a) have the factory method return an Object. This way you will always have to cast to the correct class though.
I dislike this option since clients have to know concrete implementation. Thus, creating couple between the clients and services.
A a = A_Factory.getService();
....
....
C c = (C) A;

If C has been modified to add an additional method; the client would need to know.

I am thinking using the adapter pattern to make unique methods having the same signatures and then push them up to the abstract class A, but this would over kill. Is there any other option?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you have a solid goal of class X being able to work with A, B or C without having to know exactly what type it is, an adapter or decorator might not be overkill. I have exactly that requirement nowadays - X must be able to handle A,B,C and unforeseen new classes (maybe D, E, F) without touching the code in X.
 
Joe Nguyen
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think using adapter or decorator would add an additional layer in between, and thus makes the code unclean and hard to maintain.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Casting and instance of checks for dissimilar classes forces maintenance - every time a new class is introduced we have to open, change, test and release the code with some risk of breaking it. Polymorphism enables stable core code - we can introduce new classes without touching the core routines. If this is important - and it might not be in all cases - we need some mechanism to make unlike classes become polymorphic. Adapters or decorators would be a couple choices. Others?
 
Joe Nguyen
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am thinking about the command pattern. Every child class has a common interface that contains execute() method. Unlike factory method, command pattern belongs to behavioral category. The command pattern forces children classes to have the execute method. A combination of factory method and command pattern would be better, don't you think? The factory method returns an interface/abstract class which has the execute() method. Since user only needs to know the execute() method, modifying the implementation won't affect the user.
Comment?
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Joey

Yeah, I liked command pattern idea but make sure you don't end up misusing it

Regards
Maulin
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Command has been very very good to me. I use it very much. (I'm sorry, I have no idea where that accent came from. I haven't seen Garret Morris for decades.) But command goes beyond mere polymorphism to the point where execute() has no semantics. It could do absolutely anything (which is why I like it in the right place.) A polymorphic computeInterest() for example has a bunch more meaning to a reader.
[ June 29, 2004: Message edited by: Stan James ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic