Re: Access subclass attributes from base

Remember that it's totally irrelevant if it's neat in *theory*. A framework
should be offering *practical* benefits. So now we've got the sermon out of
the way, let's look at the actual issues.

We're not talking theory here, but a set of objects that share a common
creation strategy in a distributed COM+ environment where logging and other
corrective measures to ensure the client obtains an instance of the object
need to be taken. The approach originally recommended by Microsoft was a
factory object with the interface described earlier that implements more than
a few lines in the actual factory method and needs to be applied to every one
of our factories.

Are you omitting the actual factory methods? That doesn't exactly make
things clearer. I'm assuming "Instance" is intended to be the factory
instance, but then that's belied by this:

I was only including the interface definition to keep the post focused on
what's important. The Instance property is the factory method that utilizes
the generic information to create and return an instance of
TConcreteImplementation conforming to TInterface. It would be more
appropriate to have this be a GetInstance() method instead of a property, but
that in no way affects the functionality.

Why do you need to mention "BusinessObject" at all at this point? Isn't the
factory implementation the thing that has to deal with BusinessObjects
eventually? Then let that take care of it and don't hoist this dependency to
the general level, where it doesn't belong.
The subclasses only responsibility is to tell the base class to which
interface Instance must conform and which concrete class will be used in the
creation, so this is the only point in the creation process in which
BusinessObject matters at all.

You can use Object.GetType() to get the concrete type of the instance, and
Type.GetAttributes() to get the attributes of that type.
I was trying to find a way to accomplish this from the static factory
method, but it looks like I may need "this" in order to obtain the attributes.


"Jeroen Mostert" wrote:

Kyle M. Burns wrote:
Using the 2.0 framework, I'm trying to flesh out an idea that I had for a
generic factory using an attribute to specify the type of concrete class that
will be implemented.

Be careful about ultra-genericity. It looks really neat on paper, but when
you're finally done and take a step back you usally find out that you
haven't actually gained any flexibility or safety that you couldn't have
achieved with Plain Old Code, and you've atually saddled your clients with a
big learning curve when they try to understand what the hell is going on
(and they always eventually need to understand what the hell is going on,
since the perfect framework exists only in dreams). I've fallen into this
trap more than once. .NET makes it easy for you by having both generics and
metadata.

Remember that it's totally irrelevant if it's neat in *theory*. A framework
should be offering *practical* benefits. So now we've got the sermon out of
the way, let's look at the actual issues.

> Our base factory does all the work and looks like this:

abstract BaseFactory<TInterface, TConcreteImplementation>
{
static TInterface Instance { get; }
}

Are you omitting the actual factory methods? That doesn't exactly make
things clearer. I'm assuming "Instance" is intended to be the factory
instance, but then that's belied by this:

With subclasses implemented using code like this:

FBusinessObject : BaseFactory<IBusinessObject, BusinessObject>{}

Is this class supposed to have an Instance of type "IBusinessObject"? If so,
how is this a factory? "BusinessObject" could implement the singleton
pattern itself. Don't you mean it has to have an Instance field of type
"FBusinessObject"? The *factory* being a singleton would make more sense
(even though there's still no reason why you should decide that all
factories have to be singletons!)

I hope "Instance" isn't supposed to be the thing that returns multiple
different objects! Using a property for that is totally inappropriate.

[ConcreteImplementation(typeof(BusinessObject))]
FBusinessObject : BaseFactory<IBusinessObject>{}

then I could have clients of the factory only need to know about the
assembly containing the interface and that containing the factory.

Why do you need to mention "BusinessObject" at all at this point? Isn't the
factory implementation the thing that has to deal with BusinessObjects
eventually? Then let that take care of it and don't hoist this dependency to
the general level, where it doesn't belong.

You seem to have created the problem for yourself by insisting that a
super-generic base class contain it all. This doesn't actually help the
subclasses. For example, how is this base class supposed to know how to
instantiate concrete classes? Haven't you locked yourself into a design
where all objects must have a default constructor or some other "one size
fits all" creation pattern? What's the benefit there, and how would it hurt
subclasses to have to write out that construction themselves?

The problem is that I'm not finding a way to access the attributes of the
subclass from within the base class. Any thoughts on how/if this can be done?

You can use Object.GetType() to get the concrete type of the instance, and
Type.GetAttributes() to get the attributes of that type. So:

abstract BaseFactory<...> {
public void Foo() {
ConcreteImplementationAttribute cia = (ConcreteImplementationAttribute)
Attribute.GetCustomAttribute(this.GetType(),
typeof(ConcreteImplementationAttribute));
// Use cia here
}

}

The usual caveats apply: reflection is slow when not carefully applied and
adds to maintenance costs by introducing hidden dependencies. In this case,
it really doesn't seem worth it. You're writing more framework code than
code that actually *does* something, and it doesn't seem to give you
anything in the way of reusability and flexibility. If all you're trying to
do is saving the clients from writing what appears to be one line of code,
don't bother.

--
J.

.

Relevant Pages

  • Re: Unification of Methods and Functions
    ... I am suggesting that we write factory methods using classmethod to give ... my classes all implement an interface which I'll call 'shape ... Rectangle and Ellipse have a common base class, ...
    (comp.lang.python)
  • Re: OO, I just dont get it.
    ... They are called "Factory Methods". ... You ask whether the base class Document and a subclass MyDoucment are ... subclasses of the factory returning instances created in different ways. ...
    (comp.object)
  • Re: Factory method
    ... The base class must not create the children. ... If you don't want a public constructor, then define a Factory ... >I have an abstract class, and a set of classes that inherit from my ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to implement Factory Pattern in Java
    ... > a static getClass method in the base class? ... > Rather than instantiate a factory, then call its getClass method (2 ...
    (comp.lang.java.programmer)
  • Re: Access subclass attributes from base
    ... generic factory using an attribute to specify the type of concrete class that will be implemented. ... You seem to have created the problem for yourself by insisting that a super-generic base class contain it all. ... This doesn't actually help the subclasses. ...
    (microsoft.public.dotnet.framework.clr)