Not a problem. Just didn't want anyone else to get the wrong impression. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
On Wed, June 1, 2005 10:35 am, Dakota Jack said: > Sorry, Frank. I did not mean to misrepresent you in any way but > merely to use a jocular reference out of good nature. I know you are > into OOP. > > 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] >> >> > > > -- > "You can lead a horse to water but you cannot make it float on its back." > ~Dakota Jack~ > > --------------------------------------------------------------------- > 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]
