Creational design patterns

[Guest]

I have been trying to wrap my head around design patterns
in c# and am very new to this.

I do not understand the point of using factories to create
objects. My understanding is that creating factories to
initialise objects has the benifit of allowing you to
easily add classes without modifying the code.

However in saying this, creating new classes usually
requires requiring new input for the constructors when
requires a change to feed the right data into the factory
to use its constructor anyway. Could anyone here
elaborate on my problem?
Regards
Dan

 

[Aravind C]

Hi,

If your class factory supports the creation of objects that accept
different types of constructor parameter arguments , you may also like
to consider exposing a Create method in your factory that accepts an array
of
generic System.Object objects, which contains the parameters to
initialize your object with.

MyClassFactory.Create(String className, Object[] constructorParams);

When the factory creates the object via reflection, the right
constructor would be invoked based on the type and number of
the parameters passed in constructorParams.

Regards,
Aravind C

 

[Yura2000]

Hi!
For right using of patterns you need right architecture
and right implementation.
When ou use Factory pattern you can pass as argument any
object that implements any generic interface.
In Factory method u can check what type of this object and
return something expected for this type.
For instance, u pass object implements IEmployee interface.
Within pattern you check something like this:
if (objEmployee is Manager)

 

[Yura2000]

Hi!
For right using of patterns you need right architecture
and right implementation.
When ou use Factory pattern you can pass as argument any
object that implements any generic interface.
In Factory method u can check what type of this object and
return something expected for this type.
For instance, u pass object implements IEmployee interface.
Within pattern you check something like this:
if (objEmployee is Manager)
<your code here>

I hope it will help u.
Regards

 

[Guest]

My question still remains unanswered. What is the
difference from calling the constructor directly instead
of going through a factory.

Regards
Dan

-----Original Message-----
Hi,

If your class factory supports the creation of objects that accept
different types of constructor parameter arguments , you may also like
to consider exposing a Create method in your factory that accepts an array
of
generic System.Object objects, which contains the parameters to
initialize your object with.

MyClassFactory.Create(String className, Object[] constructorParams);

When the factory creates the object via reflection, the right
constructor would be invoked based on the type and number of
the parameters passed in constructorParams.

Regards,
Aravind C

I have been trying to wrap my head around design patterns
in c# and am very new to this.

I do not understand the point of using factories to create
objects. My understanding is that creating factories to
initialise objects has the benifit of allowing you to
easily add classes without modifying the code.

However in saying this, creating new classes usually
requires requiring new input for the constructors when
requires a change to feed the right data into the factory
to use its constructor anyway. Could anyone here
elaborate on my problem?
Regards
Dan

.

 

[Jeff Louie]

Hi Dan... Here is the list from Guy Steele
1) The methods can have unique self documenting names
2) Objects can be reused rather than constructed each time
3) You can return non public subtypes, hiding the implementation,
supporting dynamic registration of a new subtype on the fly. So you may
get back some encryption/decryption service of unknowm implentation on
the fly, as long as the new service supports the base interface methods
eg encrypt, decrypt etc.

Regards,
Jeff

My question still remains unanswered. What is the

difference from calling the constructor directly instead
of going through a factory.<

 

[Jeff Louie]

Second try at posting. 1) Lets you use self documenting names and
redundant parameter lists. 2) Allows the reuse of existing objects 3)
Allows dynamic instantiation of non public subtypes eg. registering a
new crytography service and returning an instance of the new service
when you only know the interface type. Adding new choices to a menu
item when you only know the supported interface of the menu item.


Regards,
Jeff

 

[Daniel Billingsley]

Dan, the factory shields from the underlying implementation. That is to
say, it is classic OO.

Data access is a great example. You can write a factory that returns a
IDbConnection interface and all the code "above" that point never knows or
cares whether that's a SQL Server or OLEDB connection "under the hood".