I must side with Craig's world view: <snip> > sub-apps should be as self > contained and independent as possible, in the same manner that webapps > should be as self contained and independent as possible. </snip>
OO is first and foremost about encapsulation. Your solution's objects mirror the user's mental model. Inheritance breaks encapsulation. It tightly couples subclasses to superclasses. A subclass depends on the implementation details of its superclass for its proper function. If the superclass's implementation changes from release to release, the subclass may break even though it hasn't been touched. When I model I use this rule of thumb: If inheritance isn't in the domain model, don't have it in the implementation. I try to use composition over inheritance which IMHO makes the code easier to understand. One of the biggest mistakes for Java newbies is to jump into inheritance and end up with an app made up of one huge inheritance heirarchy. It is evil to maintain - I have had to try and 'fix' quite a few. You spend most of the day traversing the heirarchy playing "find the implementation". It's tedious when you have the source but becomes evil when you have to decompile some framework's jar and find out the inner workings of superclasses. Sorry about the rant - Joshua Bloch explains it better as Item 14 in his book: "Effective Java Programming Language Guide" He helped architect & write alot of Java's collection classes which are an excellent example of how to write an API framework. It's well worth reading. Hmm sorry - probably a bit more than 2 cents... but I consider inheritance the most widely misused feature of OO languages. Jon. -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: 08 October 2002 02:42 To: Struts Developers List Subject: Re: [Proposal] Sub-application inheritence On Mon, 7 Oct 2002, Eddie Bush wrote: > Date: Mon, 07 Oct 2002 18:19:08 -0500 > From: Eddie Bush <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: [Proposal] Sub-application inheritence > > Sub-applications in Struts 1.1 are one of the biggest advantages over > 1.0. They let you break your configuration apart into multiple pieces - > so that different people can work on their piece of the project without > affecting others. This is good for those of us working in a > team-oriented setting where different (groups of) people may be > responsible for different function areas (ok, Bob and Henry - you guys > get the account-maintenance stuff - Frank, Nancy, and Richardo - you > guys get this 'store' module - etc). Still, sub-applications aren't as > functional as they "could be". > > Because of the structure imposed on sub-applications [1], I think > several people believe it would be reasonable for sub-applications to be > able to share information with one another[2]. I believe it is expected > behavior, in fact. > There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's "single sign on" plus not having to copy your JAR files into things like "$CATALINA_HOME/common/lib" in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. > Currently, each module loads whatever resources it will need. As a > result, there is unnecessary duplication of certain resources. Some of > those particular resources result in wasting RAM, while others have a > more significant impact. Of those that have a more significant impact, > the most notable is undoubtably the data-source. Data-source is handy. > It's a pool for JDBC connections. The fact that you can configure the > pool to limit connections is undoubtably an important functionality to > those who use it (though I can't say with full certainty, as I do not > use the built-in data-source) - but now that we have sub-applications, > determining how to setup the pool to properly manage connection limits > could be quite ... difficult. Yes, there are many very good OS DBMSs > out there - but we all have to sensibly ration out our connections - if > only because of resource consumption. > > The proposal I would like to set forth is thus (this is a suggested order): > 1 - refactor data-source instantiation/acquisition so that > duplicates are not created -- *and* sub-apps would they chain the lookup > from the current module to the default module. > 2 - refactor message-resource instantiation/acquisition the same way > 3 - refactor global-forward ~kind of~ the same way. Global forwards > mentioned in sub-apps would be "pushed up" into the default module. > Yes, I know there's a possibility for clashing. > 4 - (optional) introduce module-level forwards that would replace > our current "global" forwards - and have the exact same "scope" > (visibility) as our current "global" forwards. > All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? > Disclaimer: No, I haven't yet fully studied what would have to be done > to acheive this proposal in it's entirety. I post this for open > discussion so that ideas can be generated and bad ones pruned. > > So, if you take the view that *all* sub-apps are independent of one > another - and should be - obviously this is a very stupid proposal. If, > however, you take the view that all modules are going to be developed in > support of the default module, this is a very logical following (I > think), as it lets you leverage the effort you put into the default > module in your sub-applications. > > My view on (3) above is this: I see modules as being like "classes". > All of the resources are instance-level declarations. "Global", in > this sense, would imply being available either apart from the heirarchy, > or being available in the "base class" (which I suppose puts it back at > the "instance"-level actually). > > We wouldn't break backward-compatability (that I can think of), since > the changes would be primarily geared toward allowing non-default > modules to access the default modules resources. Nothing (that crosses > my mind!) would have to change for the default module (save for > "global-forwards" being "pushed up" into the default sub-app -- this > wouldn't impact a 1.0 app moving to 1.1 in the slightest). > Fundamentally, your proposals change an individual struts-config.xml from being a self contained description of a module to a *partial* description of a module that cannot be installed and run by itself. Personally, I'd rather spend a couple of hundred extra bucks for a few more megabytes of memory than to suffer the complexity costs of this. > I suppose, since, as Ted observed, we're involved in "feature lock", > this is something that is viewed as an "enhancement" or a "bug" request. > My view is that it is a bug, but I have to admit I'm unsure about what > precise functionality you all expected to have in 1.1. I should > probably go check the release plan :-), but I don't recall anything > supporting this being there -- nor do I recall seeing anything that > would inhibit this being there :-) > > Is this a "post 1.1" thing? Is this even a desirable thing (I believe > it is - what's your opinion)? > Post 1.1 enhancement request. > (Would the changes necessary to implement 1 & 2 really be that > significant? Those are the really important items as I see it.) > It's not so much how big the effort is, it's that you are changing the semantics of how things work in 1.0 and 1.1b2. That's a very significant issue. NOTE - that is not at all to say that it's a bad idea on its own merits. I just think it is not appropriate for 1.1 implementation. > ------------------------------- > > [1] - Sub-app partitioning gives us something like: > > (default) > > / \ > Foo Bar > / \ > Baz Bang > I imagine Martin will like this a lot :-). > > [2] - At least non-default sub-apps to share information from the > default sub-app. From [1], Foo would have access to the default > sub-app's config, as would Bang. > > -- > Eddie Bush > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
