Good stuff Frank. Your point is a good one and well made. I just spoke at a Java User Group here in Wisconsin on a similar issue, about how most people don't need to improve their Java programming skills, rather they need to improve their programming skills!
I think that pattern use falls in the same area. There are folks that use patterns religiously, thinking that they're being good programmers. All the while not realising that they're reducing themselves down to the level of a coding monkey. Too much of the Java code that I see is not object-oriented, it's object-obsessed. Objects defined for any small silly thing. Wrappers upon wrappers, calls to super in multiple levels of inheritance. Arrgh. It's like trying to follow the plot of one of Frank Herbert's Dune novels. (Good for novels, bad for programs though!) Simon On 6/1/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Wed, June 1, 2005 9:47 am, Dakota Jack said: > > This is what our > > fellow traveler Frank Zammettie finds inherently suspicious about the > > *OOP nuts*. > > Woah, leave me out of this. I've purposely stayed away from this thread > all this time, now I have to get in... > > I don't want anyone thinking I'm anti-OOP or anything remotely like that. > I am very much an OOP proponent. While I almost certainly have used the > term "OOP nuts" at some point because I think some people could probably > be described that way, that really sounds a lot more harsh than my opinion > actually is, so let me clarify... > > What I have said is that I have seen many instances where people take the > OOP exercise so far in trying to get a perfect architectural structure in > place that they wind up writing code that is actually harder to understand > than it otherwise could be. There is great benefit to writing code that > is composed of smaller, largely interchangeable pieces rather than large > monolithic pieces. We all know this. However, I have seen this taken so > far that it takes forever to grasp how all the pieces fit together to form > the larger whole, and this is just as bad as writing one larger whole > would have been. > > Related to this, patterns are a wonderful invention, but I see day in and > day out people trying to find a pattern for every single situation. > People seem to think that they have to solve every problem by finding a > suitable pattern. The problem is, everyone seems to be so > "pattern-gung-ho" nowadays that they simply want to apply a pattern and if > it actually makes things more complex, too bad. If it doesn't really fit > the problem but does happen to solve it, that's fine too. A pattern > mismatch, or a pattern where none was truly needed, is just as bad as no > pattern at all in my experience. > > Simplicity is a beautiful thing. That is always my underlying design goal > for two reasons... > > One, in a corporate environment as I work in, you never know when someone > else is going to have to come along and maintain your code. You aren't > doing them any favors by writing code that, while architecturally sound, > is more complex to grasp. If after three months they say "wow, this guy > architected this code perfectly!", that's great, but if those three months > are spent not being especially productive while they try and understand > what you built, then the code wasn't well-written in the end. > > Two, when you jump around between many different projects, you tend to > forget your own work quickly. I sometimes look at code I wrote just last > year and go "I don't remember how or why I did this". Fortunately I > comment the hell out of everything I do, but more importantly I try to > code in straight-forward ways. Sometimes that means *NOT* creating that > helper class to encapsulate 10 lines of code, even though that might > architecturally be better and fit some pattern, but instead just inline it > (assuming I don't expect it to be shared of course). > > In a nuthshell, my point is absolutely *USE* OOP and patterns, and other > related techniques, think in those ways all the time, but don't > over-engineer things!! Don't make design decisions because you CAN do > something, make them because it is the RIGHT thing to do. And don't > over-complicate things for the sake of achieving some theoretical design > utopia. Make your code easy to understand, even if sometimes at the cost > of design trade-offs. Naturally there is a balance to be struck... > architecture *IS* after all important! > > Frank > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
