tough question: new BaseClass but somehow giving them BaseClassInherited without static Create() typ

  • Thread starter Thread starter Eric Newton
  • Start date Start date
E

Eric Newton

Calling NEW for a particular type but actually ending up giving the caller a
derived type based on the constructor call

The problem is trying to build an extensible framework that will return the
most specialized object even through a different project...

For instance, WebRequest privatized the constructor and said "use the static
Create method" but you can't override a static method like Create [that is,
if WebRequest is even inheritable ie not sealed]
 
Wrong way to look at it. Constructors always instantiate an object of the
class the constructor is a member of.
What you are looking for is a class factory, which is exactly what the
static Create method is an example of. You may not be able to override, but
you can still shadow. Your base class will instantiate a derived class, and
your derived shadowed method will instantiate an object of its own class (if
i read your explanation correctly). If they have a reference to the base
class, it will bypass the shadowed method, but your base method will
instantiate the proper class.

However, I don't think you are approaching this problem correctly. In
particular, you will find it difficult to pull off your example scenario
because the "other" project references the project with the base class, but
the base class will need to reference the "other" project, and that isn't
allowed.

My suggestion is to forget the solution, and go back and articulate the
problem, and we'll see where we can go from there - hopefully find a more
streamlined solution. This is very counter-OOP.

-Rob Teixeira [MVP]
 
Use factory.
Like this:
class Factory
{
IBase Create()
{
return new Derived();
}
}
 
I agree, its not a very clean pattern. And I'm tending to lean more towards
[Type]Factory classes that can be derived and override the Create[Type]()
methods.

Although the static method that is simulating the Factory pattern is more
convienient. Only problem I have with shadows is that once MY class needs
to instantiate a class further down the rope then my class cant call into
the shadowed function, only the classes that are further down the chain seem
to see it.

So in actuality, a [Type]Factory class is probably the best way to go.

--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]

Rob Teixeira said:
Wrong way to look at it. Constructors always instantiate an object of the
class the constructor is a member of.
What you are looking for is a class factory, which is exactly what the
static Create method is an example of. You may not be able to override, but
you can still shadow. Your base class will instantiate a derived class, and
your derived shadowed method will instantiate an object of its own class (if
i read your explanation correctly). If they have a reference to the base
class, it will bypass the shadowed method, but your base method will
instantiate the proper class.

However, I don't think you are approaching this problem correctly. In
particular, you will find it difficult to pull off your example scenario
because the "other" project references the project with the base class, but
the base class will need to reference the "other" project, and that isn't
allowed.

My suggestion is to forget the solution, and go back and articulate the
problem, and we'll see where we can go from there - hopefully find a more
streamlined solution. This is very counter-OOP.

-Rob Teixeira [MVP]

Eric Newton said:
Calling NEW for a particular type but actually ending up giving the
Click to expand...
caller
a
derived type based on the constructor call

The problem is trying to build an extensible framework that will return the
most specialized object even through a different project...

For instance, WebRequest privatized the constructor and said "use the static
Create method" but you can't override a static method like Create [that is,
if WebRequest is even inheritable ie not sealed]


--
Eric Newton
C#/ASP Application Developer
http://ensoft-software.com/
(e-mail address removed)-software.com [remove the first "CC."]
Click to expand...
Click to expand...
 
Back
Top