• 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

Use of Factory pattern in a colocated architecure

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
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
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
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
 
It's just like a fortune cookie, but instead of a cookie, it's pie. And we'll call it ... tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic