heres mine…

Free Online Vedios http://www.flashgamesz.net/mediacentre...

Java gurus tend to get interface-happy: look at the Springframework and Eclipse sourcecode for instance: where almost every class has a corresponding interface. Do all those classes really need several different implementations? I doubt it.

They also tend to get subproject-happy: applications must have layers and these layers must be clearly separated; The "presentation layer" must not touch "data objects" directly, we need "domain models"; or, Let's have a subproject for each layer of the application to reduce coupling, parts of it can also be reused in other projects. Does the reuse really happen down the road? I won't say never, but I think rarely.

In general terms, the Java Philosophy is this: keep modules isolated, so that they can be resistant to change. Because you never know when you are going to need to swap out your UI layer, business layer, data access layer, or your persistence engine, or your database, or your JMS provider, or your J2EE container, or your OS, etc, etc.

I am not dissing this philosophy, it is very useful to be able to swap out some of these components, but others, not so much. There's a balance somewhere. I think that in a lot of cases simply refactoring code is enough to cope with change. It really isn't hard if you keep your code DRY, and have good test coverage. Java folks in general are just too in love with the idea that their finished code should work with every imaginable situation that can arise.