Factory pattern and overriding
Hi all,
I'm currently refactoring an application which uses two different libraries according to the user input.
There is a Factory class who returns instances of, let's say, MetadataB and MetadataB, both subclass of Metadata.
This is fine if the user calls one of the method exposed by the superclass Metadata, because under the hood it is the concrete implementation of the subclass that works.
Now, I would like to add some methods to one class but not the other, and expose them to the user according to her initial choice.
This breakes the previous pattern.
Any solution for this refactoring? (can't ask the user to make an explicit casting)
Thanks a lot
[712 byte] By [
Dylan68a] at [2007-10-2 10:34:48]
Would use of the Decorator pattern help out? Take a look at how the Collections API exposes additional methods on the same interface or abstract class.- Saish
Well, I think that the Collections will let me to custom the behavior of some data.What I need, is the dynamic creation of methods.I've seen that the Proxy class in the reflection might help. Any suggestion/warning?
The Proxy class will work for you. However, how would you have designed this in, say, 1.3? The fact that you are looking for dynamic, runtime method insertion indicates to me a problem with your design.- Saish
Yes, you are right. Point is that I did not design the application ;)
I'm asked to extend its functionality.
So, either I break the Factory class, (I'd do that if i could re-design from scratch) forcing the client to call the correct class, namely MetadataA or MetadataB (which would require to change the client code) or I have to use some workaround (personally I don't like reflections)
Thanks for your suggestions, they were useful.
> I'm asked to extend its functionality [but don't want/can't] require
> to change the client code)
Maybe it's just me, but I don't understand your specific requirement : in the beginning you talk about adding new methods and expose them to the user : what do you mean by user? End-user? Client code?
1- If the new methods are new APIs : I don't see how client code can leverage new APIs without evolving to call them
2- Now if these new methods are not new public APIs but new implementation helpers, I can imagine how you want MetadataA and B to call them, but then you can change MetadataA and B, I don't see how client code is impacted.
3- Now maybe I misunderstood you, and you can afford changing the client code to invoke new functionalities, just not the creation part. Then there are cast-less ways to achieve that cleanly (Adapter, Decorator, Visitor,...).
Just give a bit more clue as to what you're after.
Humbly,
J.
Okay, let's start again from the beginning.
> Hi all,
>
> I'm currently refactoring an application which uses
> two different libraries according to the user input.
>
When you say 'libraries', do you mean classes, packages or JAR files?
> There is a Factory class who returns instances of,
> let's say, MetadataB and MetadataB, both subclass of
> Metadata.
>
No issues here. Though, I am assuming one is in fact MetaDataA and the other is MetaDataB.
> This is fine if the user calls one of the method
> exposed by the superclass Metadata, because under
> the hood it is the concrete implementation of the
> subclass that works.
>
Inheritance and polymorphism.
> Now, I would like to add some methods to one class
> but not the other, and expose them to the user
> according to her initial choice.
> This breakes the previous pattern.
> Any solution for this refactoring? (can't ask the
> user to make an explicit casting)
>
Again, take a look at the Decorator pattern. However, there are a number of terms in here causing me concern. How would you 'expose' certain methods to a user based on a choice? Further, how would a user ever initiate a run-time cast? What is the user actually doing?
> Thanks a lot
- Saish
