theoretic question: extends vs. managed property

[Philippe Lamote <ph...@mac.com>]

Hi List,

I have a more theoretic (setup) question:

Suppose you have an app with some management handling to do.
There is a big general part, but also typically specific parts.
You don't want to become one bean bloated as hell, so you make a bean  
A for common, general issues (common vars, inits, ...) and have beans  
of type B handling each of the specific issues, using this core.
Now, there are perhaps two obvious ways of doing this:

- with more OO-DNA: having beans of type B extend bean A.
- with more JSF-DNA: declaring bean A as a managed property of Bean  
A. (so no "extends", but an instance var of type A in B, that gets  
injected by JSF)

There are go-between cocktails, like Bean B having an instance var of  
type Bean A -without any "extends"- and have this instance injected  
with a bean of type A in B's constructor via a hard FacesContext  
lookup; the manual way of the 2nd option. Or with Spring (JSF-Spring  
integration woes) Or...
But I'd mainly like to focus on the differences between the 2 given  
options. :-)

--> What would be the nuances between these two?

I'll start off:
- should you change Front-end FW, the 1st would probabely require  
less rework.
- the code is a little cleaner in the 2nd case (no need to check  
wether bean A is booted already (in B's constructor)) (so no line  
like "if(!super.isBooted())super.init();" in B's Cstr)
- the 1st option may reduce object creation, but I'm not sure of  
this. I think in the 1st option, only one A gets created, with the  
2nd option JSF may (?) inject every single bean of Type B with its  
own copy of bean A. (even worse, all beans of the same B with their  
own copy of A --> # of A is lineair with beans of type B)
- I don't think there any differences in life cycle.

Any other ideas?
Phil