Re: Access subclass attributes from base

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Kyle M. Burns wrote:
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.

In that case, you have my condolences. DCOM is no fun.

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.

So you have share functionality (actually, it sounds more like *identical* functionality to me). There are still quite a lot of ways to implement that.

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.

Alright, I have a clearer picture of what you're trying to achieve now.

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.

Yes, you will. But there doesn't seem to be any pressing reason to muck about with attributes. From what I've gathered so far, your base class does *everything*, including the instantiation, so I gather it has some way of instantiating a business object given its concrete type. How about:

static class BusinessFactory { // Or make it a singleton
public static IBusinessObject CreateBusinessObject<IBusinessObject, TBusinessObject>() {
/* Instantiate a new TBusinessObject here, return as IBusinessObject*/
}
};

public class WidgetFactory {
public IWidget CreateWidget() {
return BusinessFactory.CreateBusinessObject<IWidget, Widget>();
}
}

Add interfaces and subtyping where necessary. Since WidgetFactory only uses the concrete Widget type in its method, not its type signature, there is no dependency between the clients of WidgetFactory and the Widget. Or are you worried about some other dependency? It's not completely clear to me. Note that there is obviously no way to avoid some dependency between WidgetFactory and Widget, since it will have to pass the type to the business object factory somehow! If you want to remove *all* compile-time dependencies, you'd have to use reflection to dynamically get the types, but this seems far more trouble than it's worth.

--
J.
.

Relevant Pages

  • Re: why a factory class?
    ... >> The creation of objects is actually a secondary point of the Factory ... "Uncle Bob" sycophant terms for using abstract interfaces to concrete ... dependency - compilation and linking - on lower levels STILL certain ... all MANDATE higher levels eve depending upon abstract interfaces to ...
    (comp.object)
  • Re: graph of behavior - was Re: State vs. Data (was Re: Fans of Template Method with protected varia
    ... >>factory is dependent on the implementation of the classes ... to concrete classes to reduce dependency] while higher levels minimize ... static dependency - compilation and linking - on lower levels STILL ...
    (comp.object)
  • Re: Association and depency
    ... >> Dependency are represented correctly in code? ... >Here the Car class must exist in order for the Factory class to work, ... >howver the Factory objects send no messages to Car objects, ... The folks behind UML have done a very poor job of explaining UML, ...
    (comp.object)
  • Re: passing a Factory to a method to create a generic instance
    ... Does there have to be a Nut factory, or can I just use the Widget factory? ... I'm not seeing the advantage of WidgetFactory, ... Guest extends Data //Data is just the name of package ... public class DataFactory implements Factory{ ...
    (comp.lang.java.programmer)
  • Re: Association and depency
    ... >> Dependency are represented correctly in code? ... > Driver is associated with License in the above code. ... > Here the Car class must exist in order for the Factory class to work, ... > howver the Factory objects send no messages to Car objects, ...
    (comp.object)