I got acquainted with software design patterns when I was in my first senior year in college (first of my two senior years, I had two because I was delayed by a year). It was introduced to me by my brother Nikki and his pal Celsus because I kept on bugging them on how to design good software. It was the term when I had to do my Special Problem (an equivalent to the thesis). Back then, I was too naive to think that having a breadth of knowledge on the patterns was sufficient to get me going on my framework project. Hell, I even memorized the patterns in the GoF book. However, that idea has driven me to a dead-end rather than a quick start because I was never aware that I neglected the base principles from which the patterns were derived.
I was more of complicating the problem than solving it.
My mistake was to NOT analyze the problem based on the principles of object oriented design. I just thought of: use-this-pattern-for-this-problem-because-the-book-says-so. Six different patterns for two dwarf-sized modules to show-off was a bad idea. I had to redo everything in the end, keeping it simple as I go and using only the necessary patterns. Using patterns in the wrong context is indeed a fallacy. It took me a while of bashing to realize that. Yeah, a common mistake among novices. I guess most of us experience that once in our software design life, huh?
That's one reason why I'd never go trolling on mailing list saying, "Hey bud, you got that wrong. Don't use that without even knowing how and why it works." Another reason is I'm too lazy to discuss it, so I'd go "Better RFTM the way I did it" at them. Haha! Though it's another story when seasoned developers play the stubborn i-know-better-than-you arrogance on misused designs.
Just recently, I had a talk with this schoolmate of mine who keeps on pushing JUST the principles. He didn't like how complex the design buzzwords were so he said that the principles alone could get him up to level among the seasoned software architects.
Good enough, but not good for long.
My take on this is he'll reach the patterns while refactoring, eventually. But knowing and applying the patterns will speed the development much faster and avoid drastic refactoring. Besides, that's what the patterns are there for--it serves as a reference to problems identified and solved before. It also provides a common vocabulary among designers. So when we discuss designs, we are sure to be on the same line of thought. It will give us some advanced level of abstraction that will ease the way we understand systems. Never before has software designing been this unburdening. I hope he gets what I mean. It's just time we take advantage of knowing more.
What's your thought on this?
By the way, nothing offensive meant in the entirety of this entry.
Flame suit on, nevertheless.
2 comments:
First things first: You know Celsus? Like Celsus Kintanar? O_O If it's him, I'd say it's a small world... We came from the same high school and he's one batch younger than I am basically.
Thoughts on buzzwords: In domain driven design, we see how important it is to have a common language. And if it's necessary to study it, go ahead. It would make communication easier.
In any case, _maybe_ your friend was talking about the approach to learning things, hence the emphasis on principles. So that whatever it might be called you'd know what it is essentially. Something like that. Get what I mean? :) But eventually he'd probably 'get' and appreciate those buzzwords :)
Yep, we know the same Celsus.
Anyway, I think I can settle on thinking that my friend opts to take things as they come, in the ideals of pragmatism. That way, I too would be reminded not to overdo stuff I get myself engrossed with--especially when they're not work-related. :)
Post a Comment