Builder or Factory Pattern
Lee Jenkins
Hi all,
I asked and touched on this subject before, but am still a little undecided as
to the best course of action.
I have an application that will need to construct orders (invoices) with
products. The problem here is that the products are pretty diverse in their
individual make up and why they are constructed.
For instance, some products include one or more "side" products which must be
chosen at design time. At first glance, I thought Factory Pattern, but with the
complex "choices" that might be required in the building of the product, I
thought maybe Builder pattern would be more appropriate.
Thank you!
--
Warm Regards,
Lee
Qi
If I were you, I would consider it in a reasonable way rather than
choosing a pattern. IMHO, not single pattern or simple patterns
combination can solve a complex problem.
For your problem, I will think in this way,
1, The application should not know how the orders are constructed.
It should only know an interface (maybe a function) that can
give it an constructed order.
2, The interface (let's say it's Interface A) may or may not know
how all products' details.
If there are too many products, maybe each product (or each same
kind of products) should expose another interface (B) to interface A
so that A don't need to know each product's details.
Only interface B know how to construct an order.
3, All products can register or unregister B dynamically, so it's
very easy to plugin or unplugin a new product at runtime.
Maybe this point is not your need. Only a hint!
4, To implement interface B, you may need some other patterns,
depending on how many and what type of "side products" there are.
--
Denomo: memory and resource leak detection tool, free open source
CodeHook: Win32 code/API hook for Delphi & C++, free open source
http://www.kbasm.com/
Daniele Teti
[cut]
> I have an application that will need to construct orders (invoices) with
> products. The problem here is that the products are pretty diverse in
> their individual make up and why they are constructed.
>
> For instance, some products include one or more "side" products which
> must be chosen at design time. At first glance, I thought Factory
> Pattern, but with the complex "choices" that might be required in the
> building of the product, I thought maybe Builder pattern would be more
> appropriate.
Have you already thought to Composite pattern? (link between "master"
anche "child" product)
Then you can create your Composite "Product" with an Abstract Factory
(or Builder)
--
Daniele Teti
Andrea Raimondi
If I was you I'd use a decorator pattern along with a builder pattern for
complex products.
Peripheral products(i.e. the ones you can choose along with main product)
should be decorations of the main product.
At this point, with your decorations and main products, you build order rows
dynamically and have your
business order class just refer to the items generated by runtime products.
Does this make sense to you?
Cheers,
Andrew
Bob Dawson
>
> I have an application that will need to construct orders (invoices) with
> products.
Before leaping to the 'how' patterns, flesh out the objects: an invoice does
not contain products--it contains InvoiceLineItems--and the two are not the
same.
As you note, products can be widely dissimilar (manufactured items, stock
items, re-purchased items, kits, etc). If the only thing these have in
common is being able to be represented on an invoice, then that feature
starts to look like a distinct class/interface.
IME there are several distinct problem domains here: sales, manufacturing
control, inventory management, shipping, etc. Nouns like 'Product' mean
something different in each domain, and if you try to build a class that
satisfies them all you're going to have major issues.
bobD