Re: Access subclass attributes from base

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: Access subclass attributes from base
    ... factory object with the interface described earlier that implements more than ... The Instance property is the factory method that utilizes ... The subclasses only responsibility is to tell the base class to which ... super-generic base class contain it all. ...
    (microsoft.public.dotnet.framework.clr)
  • 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)
Loading