This week's book giveaway is in the Server-Side JavaScript and NodeJS forum.
We're giving away four copies of Modern JavaScript for the Impatient and have Cay Horstmann on-line!
See this thread for details.
Win a copy of Modern JavaScript for the Impatient this week in the Server-Side JavaScript and NodeJS forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

encapsulating object creation behavior

 
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Design question: I have an "Order" object that can be created using a "DTO" object, a Datbase Model Object, or an int. If I make constructors for each of these object types, the class would get very heavy. Is it advisable/okay to create a builder class that would create Order objects based on the parmater to the buildOrder method? Would this be considered a Factory, since typically factories create differnt objects, not just the same object from different objects?
 
author and iconoclast
Posts: 24203
43
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It would indeed be a fine thing to do; it's even fashionable, under the name "dependency injection". Note that aside from making the Order class simpler, you also keep Order from having any dependencies on the DTO or model classes -- a good thing.

Is this a factory? Yes, absolutely. A factory doesn't need to create more than one kind of object, nor does it need to have only one creation method per product class.
 
John Molitor
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the info.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ernest Friedman-Hill:

Is this a factory? Yes, absolutely.



Well, depends on whoms definition of "factory" you use. As far as I can tell, there is no single agreed upon definition of the term in the community. (It definitely is *not* one of the GoF patterns Abstract Factory or Factory Method.)
 
John Molitor
Ranch Hand
Posts: 39
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to be clear, if I have a DTO and want to convert that to a domain model object, it is recommended to have a factory or builder class that would take the DTO and convert it into a populated domain object.

One step further. If I have a DeskOrderDTO and a CabinetOrderDTO object, that both extend the OrderDTO object, would it be best to:
1. have a single "OrderDTO" factory that has a createDeskOrderDTO() and a createCabinetOrderDTO(), and reference them directly, or
2. Have a DeskOrderDTOFactory and a CabinetOrderDTOFactory that extend an abstract OrderDTOFactory, and somehow get the correct factory for the implementation that I need.
I don't want to build a rocketship, if I need a paper airplane.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by John Molitor:
Just to be clear, if I have a DTO and want to convert that to a domain model object, it is recommended to have a factory or builder class that would take the DTO and convert it into a populated domain object.



I'd probably start with a simple, static creation method, perhaps on its own class. (As an aside, take a look at http://www.martinfowler.com/bliki/LocalDTO.html and see whether it applies to your system.)


One step further. If I have a DeskOrderDTO and a CabinetOrderDTO object, that both extend the OrderDTO object, would it be best to:
1. have a single "OrderDTO" factory that has a createDeskOrderDTO() and a createCabinetOrderDTO(), and reference them directly, or
2. Have a DeskOrderDTOFactory and a CabinetOrderDTOFactory that extend an abstract OrderDTOFactory, and somehow get the correct factory for the implementation that I need.
I don't want to build a rocketship, if I need a paper airplane.



How do you decide which Order object to create? How would you benefit from the polymorphism provided by 2.?
 
See where your hand is? Not there. It's next to this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic