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]
