Factory method

[Mark]

I have an abstract class, and a set of classes that inherit from my abstract
class. The fact that it is abstract is likely irrelevant. I have a static
factory method in my abstract class that creates subclasses. The
constructor in my subclasses must be able to call the constructor in my base
class. For the factory method in my abstract class to call the constructor
on my subclasses, the constructor in the subclass MUST be public (or
internal). They cannot be private or protected. However, doen't that
basically defeat the purpose of factory? I'd love to be able to make all
these constructors private or similar so that someone can't create subclass
instances without using the Factory. If this was all in a separate DLL, I
suppose I'd be saved by "internal", but we have small team of developers
working on projects where that type of seperation really shouldn't be
necessary.

Suggestions? Code sample below ...

Thanks in advance.

Mark
public abstract class MyBase
{
protected string first;

public MyBase(string first )
{
this.first = first;
}

public static MyBase Factory(int stateId)
{
switch (stateId)
{
case 700:
return new MySubClass1(fir st);
default:
throw new Exception("Bogu s code!");
}
}
}

[James Curran]

Well, yes, but then, having the base class have any knowledge at all
it's derived classes defeats the purpose of OO.

--
--
Truth,
James Curran
[erstwhile VC++ MVP]

Home: www.noveltheory.com Work: www.njtheater.com
Blog: www.honestillusion.com Day Job: www.partsearch.com

"Mark" <Ma**@nowhere.c om> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...

I have an abstract class, and a set of classes that inherit from my abstract class. The fact that it is abstract is likely irrelevant. I have a static
factory method in my abstract class that creates subclasses. The
constructor in my subclasses must be able to call the constructor in my base class. For the factory method in my abstract class to call the constructor on my subclasses, the constructor in the subclass MUST be public (or
internal). They cannot be private or protected. However, doen't that
basically defeat the purpose of factory? I'd love to be able to make all
these constructors private or similar so that someone can't create subclass instances without using the Factory. If this was all in a separate DLL, I
suppose I'd be saved by "internal", but we have small team of developers
working on projects where that type of seperation really shouldn't be
necessary.

Suggestions? Code sample below ...

Thanks in advance.

Mark
public abstract class MyBase
{
protected string first;

public MyBase(string first )
{
this.first = first;
}

public static MyBase Factory(int stateId)
{
switch (stateId)
{
case 700:
return new MySubClass1(fir st);
default:
throw new Exception("Bogu s code!");
}
}
}

[Ollie Riches]

check out the definition here

http://www.dofactory.com/Patterns/PatternAbstract.aspx
--
HTH

Ollie Riches
http://www.phoneanalyser.net

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a programmer
helping programmers.

"Mark" <Ma**@nowhere.c om> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...

I have an abstract class, and a set of classes that inherit from my abstract class. The fact that it is abstract is likely irrelevant. I have a static
factory method in my abstract class that creates subclasses. The
constructor in my subclasses must be able to call the constructor in my base class. For the factory method in my abstract class to call the constructor on my subclasses, the constructor in the subclass MUST be public (or
internal). They cannot be private or protected. However, doen't that
basically defeat the purpose of factory? I'd love to be able to make all
these constructors private or similar so that someone can't create subclass instances without using the Factory. If this was all in a separate DLL, I
suppose I'd be saved by "internal", but we have small team of developers
working on projects where that type of seperation really shouldn't be
necessary.

Suggestions? Code sample below ...

Thanks in advance.

Mark
public abstract class MyBase
{
protected string first;

public MyBase(string first )
{
this.first = first;
}

public static MyBase Factory(int stateId)
{
switch (stateId)
{
case 700:
return new MySubClass1(fir st);
default:
throw new Exception("Bogu s code!");
}
}
}

[PIEBALD]

I've been looking at factories today too (as a work-around for the lack of
virtual constructors). It seems that factories work best when the class
doesn't use a parameterized constructor, but has a virtual method to
initialize the new instance. This creates a two-step process:

MyClass x = new MyClass() ;
x.Initialize ( ... ) ;

That first line means that you still need a specialized factory for each
class, yuck.

Ergo, I have devised the following scheme, which has its own shortcomings...

I defined an interface:

public interface IConstructable
{
void Constructor ( params object[] Params ) ;
}

(It sure would be nice if an interface could specify a constructor.)

And the following static factory method:

public static IConstructable
New
(
System.Type What
,
params object[] Params
)
{
IConstructable result = null ;

if ( What.GetConstru ctors().Length > 1 )
{
throw ( new System.Argument Exception ( string.Format
(
"Type {0} contains more than the default constructor."
,
What.Name
) ) ) ;
}

System.Reflecti on.ConstructorI nfo con = What.GetConstru ctor ( new
System.Type[] {} ) ;

if ( con == null )
{
throw ( new System.Argument Exception ( string.Format
(
"Did not find a parameterless constructor for type {0}."
,
What.Name
) ) ) ;
}

if ( !con.IsPublic )
{
throw ( new System.Argument Exception ( string.Format
(
"Did not find a public parameterless constructor for type
{0}."
,
What.Name
) ) ) ;
}

result = (IConstructable ) con.Invoke ( new object[] {} ) ;

result.Construc tor ( Params ) ;

return ( result ) ;
}

Then to use it for a class:

class A : IConstructable
{
private string str ;

public virtual void
Constructor
(
params object[] Params
)
{
this.str = (string) Params [ 0 ] ;
}

public override string
ToString
(
)
{
return ( this.str ) ;
}
}

And to make an instance thereof (this is the fugly part):

A a = (A) New ( typeof(A) , "A" ) ;

This one factory method works with any class that implements IConstructable,
as if 'twere a virtual constructor. But the class's Constructor method will
need to do type checking on the parameters, yuck.

Perhaps I can have it use a struct for the parameters, hmm...

Note that _ideally_ the class would not define a constructor, at most it may
define a public parameterless constructor.

Again, this was to work-around the lack of virtual constructors, so yes, an
uninformed user may call new on the class and mess things up, but I'm still
working on't.

[Nick Malik [Microsoft]]

Here's the Flaw

A a = (A) New ( typeof(A) , "A" ) ;
You used 'new'

The point of a factory is that the calling class NEVER uses 'new'

Your design is not a factory. It is interesting. Clever perhaps. I don't
expect to use it.
But it is definitely not a factory.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"PIEBALD" <PI*****@discus sions.microsoft .com> wrote in message
news:1D******** *************** ***********@mic rosoft.com... I've been looking at factories today too (as a work-around for the lack of
virtual constructors). It seems that factories work best when the class
doesn't use a parameterized constructor, but has a virtual method to
initialize the new instance. This creates a two-step process:

MyClass x = new MyClass() ;
x.Initialize ( ... ) ;

That first line means that you still need a specialized factory for each
class, yuck.

Ergo, I have devised the following scheme, which has its own
shortcomings...

I defined an interface:

public interface IConstructable
{
void Constructor ( params object[] Params ) ;
}

(It sure would be nice if an interface could specify a constructor.)

And the following static factory method:

public static IConstructable
New
(
System.Type What
,
params object[] Params
)
{
IConstructable result = null ;

if ( What.GetConstru ctors().Length > 1 )
{
throw ( new System.Argument Exception ( string.Format
(
"Type {0} contains more than the default constructor."
,
What.Name
) ) ) ;
}

System.Reflecti on.ConstructorI nfo con = What.GetConstru ctor ( new
System.Type[] {} ) ;

if ( con == null )
{
throw ( new System.Argument Exception ( string.Format
(
"Did not find a parameterless constructor for type {0}."
,
What.Name
) ) ) ;
}

if ( !con.IsPublic )
{
throw ( new System.Argument Exception ( string.Format
(
"Did not find a public parameterless constructor for type
{0}."
,
What.Name
) ) ) ;
}

result = (IConstructable ) con.Invoke ( new object[] {} ) ;

result.Construc tor ( Params ) ;

return ( result ) ;
}

Then to use it for a class:

class A : IConstructable
{
private string str ;

public virtual void
Constructor
(
params object[] Params
)
{
this.str = (string) Params [ 0 ] ;
}

public override string
ToString
(
)
{
return ( this.str ) ;
}
}

And to make an instance thereof (this is the fugly part):

A a = (A) New ( typeof(A) , "A" ) ;

This one factory method works with any class that implements
IConstructable,
as if 'twere a virtual constructor. But the class's Constructor method
will
need to do type checking on the parameters, yuck.

Perhaps I can have it use a struct for the parameters, hmm...

Note that _ideally_ the class would not define a constructor, at most it
may
define a public parameterless constructor.

Again, this was to work-around the lack of virtual constructors, so yes,
an
uninformed user may call new on the class and mess things up, but I'm
still
working on't.

[Nick Malik [Microsoft]]

The base class should not be bound to the list of possible inheriting
children. The base class must not create the children. That defeats the
purpose.

The child object can have a public constructor. That doesn't mean that you
will use it. If you don't want a public constructor, then define a Factory
Method in the base class and, in the child classes, implement the factory
method to return the object.

You won't be able to "enforce" that the child object cannot have a public
constructor. Why would you want to? But you can provide a mechanism that
the child class must implement that returns an object that derives from the
base type. The users of the class will always use this method, which means
you no longer have to worry about it. If a child class shouldn't have a
public constructor, write it so that the contstructor is private.

The constructor in your subclasses can call the constructor in your base
class. See this topic from Jon's site:
http://www.yoda.arachsys.com/csharp/constructors.html

To implement a factory method, in the base class define an abstract method
that returns an object of the base type.

<Warning -- uncompiled air code>

public abstract myBaseWidget
{
private myBaseWidget(in t myParam)
{
}
public abstract myBase CreateWidget();
}

public myChildWidget : myBaseWidget
{
private myChildWidget() : base(4)
{
// go do constructor things
}
public myChildWidget CreateWidget()
{
// this is your factory method!
return new myChildWidget() ;
}
}

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Mark" <Ma**@nowhere.c om> wrote in message
news:uQ******** ******@TK2MSFTN GP09.phx.gbl...

I have an abstract class, and a set of classes that inherit from my
abstract class. The fact that it is abstract is likely irrelevant. I have
a static factory method in my abstract class that creates subclasses. The
constructor in my subclasses must be able to call the constructor in my
base class. For the factory method in my abstract class to call the
constructor on my subclasses, the constructor in the subclass MUST be
public (or internal). They cannot be private or protected. However,
doen't that basically defeat the purpose of factory? I'd love to be able to
make all these constructors private or similar so that someone can't create
subclass instances without using the Factory. If this was all in a
separate DLL, I suppose I'd be saved by "internal", but we have small team
of developers working on projects where that type of seperation really
shouldn't be necessary.

Suggestions? Code sample below ...

Thanks in advance.

Mark
public abstract class MyBase
{
protected string first;

public MyBase(string first )
{
this.first = first;
}

public static MyBase Factory(int stateId)
{
switch (stateId)
{
case 700:
return new MySubClass1(fir st);
default:
throw new Exception("Bogu s code!");
}
}
}

[Steve Walker]

In message <v_************ ********@comcas t.com>, "Nick Malik
[Microsoft]" <ni*******@hotm ail.nospam.com> writes

To implement a factory method, in the base class define an abstract method
that returns an object of the base type.

<Warning -- uncompiled air code>

public abstract myBaseWidget
{
private myBaseWidget(in t myParam)
{
}
public abstract myBase CreateWidget();
}

public myChildWidget : myBaseWidget
{
private myChildWidget() : base(4)
{
// go do constructor things
}
public myChildWidget CreateWidget()
{
// this is your factory method!
return new myChildWidget() ;
}
}

Hmm. How do you create an instance of myChildWidget in order to call the
non-static CreateWidget method?

--
Steve Walker

[Nick Malik [Microsoft]]

Some mornings... I write stuff that I am embarrassed to look at later :-}

even 10 minutes later

You are correct, of course. The factory method either has to be static (in
which case, it isn't inherited) or part of another class altogether.

(duh!)
Sorry.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Steve Walker" <st***@otolith. demon.co.uk> wrote in message
news:fN******** ******@otolith. demon.co.uk...

In message <v_************ ********@comcas t.com>, "Nick Malik [Microsoft]"
<ni*******@hotm ail.nospam.com> writes

To implement a factory method, in the base class define an abstract method
that returns an object of the base type.

<Warning -- uncompiled air code>

public abstract myBaseWidget
{
private myBaseWidget(in t myParam)
{
}
public abstract myBase CreateWidget();
}

public myChildWidget : myBaseWidget
{
private myChildWidget() : base(4)
{
// go do constructor things
}
public myChildWidget CreateWidget()
{
// this is your factory method!
return new myChildWidget() ;
}
}

Hmm. How do you create an instance of myChildWidget in order to call the
non-static CreateWidget method?

--
Steve Walker

[Steve Walker]

In message <5s************ ********@comcas t.com>, "Nick Malik
[Microsoft]" <ni*******@hotm ail.nospam.com> writes

Some mornings... I write stuff that I am embarrassed to look at later :-}

even 10 minutes later
:O)

Me too.
You are correct, of course. The factory method either has to be static (in
which case, it isn't inherited) or part of another class altogether.

I find that where this happens always a thought-provoking decision.
Polymorphism is great, but at some point you have to bite the bullet and
decide exactly what it is you're going to create an instance of, and it
always seems somehow intellectually unsatisfying. I think the
subconscious appeal of the factory pattern is that you can encapsulate a
bit of code which you'd rather not see :o)

If you can justify taking the hit of using reflection, it's beautiful. I
once wrote a "generic business rules in database" type of system which
instantiated tree structures of rule subclasses by reflection, using
class names from a database. That was neat, but the logic for
determining which class to instantiate is seldom fits so well with that
approach.

--
Steve Walker

[Jon Skeet [C# MVP]]

Nick Malik [Microsoft] <ni*******@hotm ail.nospam.com> wrote:

Here's the Flaw

A a = (A) New ( typeof(A) , "A" ) ;
You used 'new'

The point of a factory is that the calling class NEVER uses 'new'

And it doesn't - it uses New, which is a method. Note the difference in
case.
Your design is not a factory. It is interesting. Clever perhaps. I don't
expect to use it.
But it is definitely not a factory.

It's not quite the normal factory pattern, but I think it's still a
factory.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too