Re: [Somewhat OT] Code organization question
Re: [Somewhat OT] Code organization question
- Subject: Re: [Somewhat OT] Code organization question
- From: Henrique Prange <email@hidden>
- Date: Thu, 26 Mar 2009 13:28:56 -0300
Hi Florijan,
Have you thought about Dependency Injection? You could use a framework
like Guice [1] to inject those properties for you.
[1]http://code.google.com/p/google-guice/
Cheers,
Henrique
Stamenkovic Florijan wrote:
Hi all,
Not a strictly WO question, but what the heck :)
I am working on moving JBND derived prop management to DataTypes (JBND's
view of class descriptions), for various reasons. In principle I am
done, and it works great. However, I am faced with the problem of
initializing those derived prop definitions. They need to be initialized
once per class, before any KVC takes place. Doing this properly is a
pain. My first idea of doing a static block per-class:
static{
// initialize stuff
}
...does not work. It causes a JC specific exception because it makes a
circular class loading situation. So, I switch to something like:
public static void initDerivedProps(){
// initialize stuff
}
This works, but it requires that the method be externally called, once
per class that contains derived props. This is a maintenance pain (and
makes me think about the concept of abstract static methods). Anyway,
I've come up with putting the following in my EO superclass:
private static final Set<Class<?>> initializedDerivedProps = new
HashSet()...;
// the EO superclass constructor
protected EOFDataObject(...){
if( ! initializedDerivedProps.contains(getClass()){
initDerivedProps();
initializedDerivedProps.add(getClass());
}
...
}
// not static, but called only once per class
protected initDerivedProps(){
// initialize stuff
}
I didn't try this out yet, but I think it should do what I want it to.
There are however two problems with it. One: it causes a
HashSet.contains(Class) call once per EO instantiation. Not a large
overhead, but it's annoying. Two: it's an ugly hack... So, I'm wondering
if anyone else has an idea for a better approach?
Thx,
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden