Inheritance isn't evil, perhaps misused but not evil. For me, it comes down to the classic is-a vs. has-a question. It seems that you have to play find-the-implementation if you use composition as well.
Dave >From: "Jon Harvey" <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: "Struts Developers List" <[EMAIL PROTECTED]> >Subject: RE: [Proposal] Sub-application inheritence >Date: Tue, 8 Oct 2002 14:59:35 +0100 > >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]> _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
