File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Use of Factory pattern in a colocated architecure Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Use of Factory pattern in a colocated architecure" Watch "Use of Factory pattern in a colocated architecure" New topic
Author

Use of Factory pattern in a colocated architecure

Mahesh Asrani
Greenhorn

Joined: Mar 03, 2005
Posts: 15
Hi All

I am not much conversant with design patterns.
In the architecture of our current project which is a colocated architecture (all business elements in the same box).

The client which calls the business components is also on the same box.
i.e all business classes are avilable to me for instantiation.

With this scenario do I need to use the Factory pattern which return me an object wrapped in an interface variable.

Cant i just instantiate my business classes in my calling client. Rather than having a factory , invoke a method on the factory to get a reference of the business object.

Do ellaborate

Bye
Mahesh
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The value of factory is when you don't want or need to know exactly the class that's being returned.

Widget a = new Widget();

Widget a = WidgetFactory.getWidget();

In the first example, I know the object I get is of class Widget. This is fairly strong coupling that may make things less flexible in the future. In the second example I know the object I get implements Widget or extends Widget or maybe is Widget.

Now the design takes advantage of polymorphism. The client code can work with Widget or any subclass. The factory can return different types on different days of the week or based on configuration or whatever logic it likes.

I wouldn't use factories and interfaces for absolutely everything (though some might make interesting arguments for that) but over time you'll start to see things that have potential to change over time and reduce your coupling through abstractions, factories, dependency injection and a number of other cool OO idioms.

That kind of question is right on target for this forum. Keep asking!


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
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
The value of factory is when you don't want or need to know exactly the class that's being returned.

Widget a = new Widget();

Widget a = WidgetFactory.getWidget();

In the first example, I know the object I get is of class Widget. This is fairly strong coupling that may make things less flexible in the future. In the second example I know the object I get implements Widget or extends Widget or maybe is Widget.

Now the design takes advantage of polymorphism. The client code can work with Widget or any subclass. The factory can return different types on different days of the week or based on configuration or whatever logic it likes.

I wouldn't use factories and interfaces for absolutely everything (though some might make interesting arguments for that) but over time you'll start to see things that have potential to change over time and reduce your coupling through abstractions, factories, dependency injection and a number of other cool OO idioms.

in order to persist my domain objs i made an interface:

now, each MyObjectDao will implement this; when i wanna, say, update, i do the following:

My Q: in my present case, what for do i need a factory?
(answer: i guess i dont )

TIA


java amateur
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Right, a factory is not required. But it might give you some ideas.

If you hand code those lines every time you need a DAO you can do without a factory. But if you'd like to move that logic into a superclass or a utility data access layer so you never have to write them again you might like something more like:

You could map object classnames to their actual DAO classes in configuration and add new objects and DAOs without ever touching this code again.

Of course it's up to you to judge if that abstraction is worth the effort in your particular app. Or maybe your next one.
miguel lisboa
Ranch Hand

Joined: Feb 08, 2004
Posts: 1281
Stan,
thanks for answering!

this is quite puzzling: i'm just starting to (really) understand polimorphism/OO and, if on one hand this is really fascinating, on the other hand i get quite insecure about all this method forwarding ...

so in this concrete case you'r suggesting that i'll write one line less then if i do it like i posted (besides being more flexible)

hmm...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Good catch - one line saved. For one line, I don't know if it's worth it. But if you move this to a single location it will only be one place to change when you want to add logging or a try-catch block or something else we can't predict. On the other hand, you can surely go overboard trying to support things you cannot foresee. If it was easy it wouldn't be any fun!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of Factory pattern in a colocated architecure