programming and human factors
by Jeff Atwood
Microsoft performance guy Rico touches on a topic near and dear to my heart
I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits. If I was to summarize my advice in that blog in a few words it would be "don't use OOP features that you don't need."Don't use fancy OOP features just because you can. Use fancy OOP features because they have specific, demonstrable benefit to the problem you're trying to solve. You laugh, but like Rico, I see this all the time. Most programmers never met an object they didn't like. I think it should be the other way around: these techniques are guilty until proven innocent in the court of KISS.This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages. Far from it, often they not only add clarity and maintainability they also improve performance. But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant. Whatever programming religion you may have I think you'll agree that more complex language abstractions do not inherently help your design -- rather each more sophisticated feature starts at a net negative and must somehow earn its way to positiveness with benefits such as clarity, ease of maintenance, performance, and so forth.
So when I say things like "don't use a delegates if regular polymorphism would do" I don't mean that you should avoid delegates I mean that you should not use them if they are overkill.
As developers, I think we also tend to be far too optimistic in assessing the generality of our own solutions, and thus we end up building elaborate OOP frameworks around things that may not justify that level of complexity. To combat this urge, I suggest following the YAGNI (You Aren't Gonna Need It) doctrine. Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become.
I agree with "sam". Can we see some examples of a good/bad obj model?
Rich on October 21, 2004 5:33 AMre: " Build what you need as you need it, aggressively refactoring as you go along; don't spend a lot of time planning for grandiose, unknown future scenarios. Good software can evolve into what it will ultimately become." From the Originator.
You must like Italian food....because that sounds an awful lot like a recipe for "Spaghetti".
Victor on October 21, 2004 5:57 AMSo, so true...
Greg on October 21, 2004 10:56 AMYour mantra is that over-engineering is bad. This is a pretty safe stance, given that "over" anything is bad (from an engineering perspective, that is, overman on the otherhand, is a taught rope..). What you fail to do is to quantify "over", simply stating "Don't use fancy OOP features just because you can." Obviously if the only reason you can come up with for justifying an architectural decision is "because I can" then it's probably not a good justification.
But the truth is there aren't a lot of "fancy oop features." There are a small set that address a large set of structural concerns. OO's mantra is "I am the machine that modifies the state that pertains to me," a concept borrowed from more mature engineering fields. In the same way that you didn't use global data in VB6, or C.. OO just gives you a structured set of extensions to excercise the same virtues.
Still, you're right, quite a few programmers do not use [or perhaps know how to use] OO effectively. But I would wager that these same people would make similarly bad architectural decisions in a procedural or functional environment too. OO is a tool. Screwdrivers don't kill people, people do.
I recently started using AspectJ on some project at home. AspectJ is a set of extensions that let me address and isolate cross-cutting concerns. It works beautifly, makes my code more clear, less littered with redundancy and makes me more prodective. I consider it a _good_ tool, despite those who would abuse it.
Perhaps you could quantify your views.. what does a "simple" object model look like compared to a non-simple or malignant design?
sam on October 21, 2004 11:10 AMI'm a professional hobbyist programmer and I'm working on about 4 projects at once.
Mainly what I'm doing is building up this one as a "really good framework" so that the others can look really spiffy and play nice. I've noticed things like having a common About Box would be cool, MDI Doc/View processing, and a couple of other things I could factor out into their own processes would be ideal.
I'm not doing that though. My goal is to make the app in a typical VB style: Everything in one place so that it looks crappy, barely functions, but gets the job done. (Okay maybe it's not typical VB but it was MY typical VB). Once I'm done I'll take out the bits I know I'll reuse, and build OOP around that. Will it be version 1? No. Version 2? Most likely. As each app grows I'm sure there will be something I can add to the functionality of the objects I made so that they perform better.
I always make that initial 1.0 crappy version though. It runs, proves that I can do it, but the code will stink completely. Version 2 or the mystical version 3 will be where the money is at, as if I'd charge for the lame things I happen to be making right now.
Honestly though, if I tried to go OOP from the beginning I'd still be in design phases trying to build up frameworks and redoing that. Rather than having a functioning product that gets the job done, I'd be spending countless hours on something I'd probably abandon within a weeks time. Then again I'm teaching myself with no idea of design guidelines, I patch together .NET code by searching for relevant information, and my knowledge of debugging comes from SalesLogix where I have to use MsgBox() to show anything useful. SalesLogix uses a scripting debugger now, but I blame them for all of the bad programming practices I've held onto for the last 5 years.
Jeremy Brayton on October 22, 2004 3:47 AMWhile I do agree with KISS and YAGNI, I also adopt many other agile methodologies. From your post I almost get the impression that you attempt to avoid using OOP (Object Oriented Programming) OOAD (Object Oriented Analysis Design) practices if possible. I on the other hand embrace OOP OOAD and attempt to take advantage of their powers whenever possible. By doing this am I somehow complicating my application/architecture? Personally I think not.
Java Kid on October 22, 2004 8:01 AMDon't Repeat Yourself is the goal I shoot for, not OOP per se:
http://www.artima.com/intv/dry.html
Sometimes OOP is the best way to achieve that, sometimes it isn't. Starting out with "well, we better use objects all over the place because there's no other way to re-use code properly!" is a self-defeating exercise.
Jeff Atwood on October 22, 2004 8:05 AMAlso, I spend a lot of time cleaning up behind people who set up grandiose object models that didn't work out.
Oh yeah? Any that I've ever seen? :-P
The way you get rid of O-R Impedance issues... is by not using the R. http://www.intersys.com. Or by using something like http://www.hibernate.org/. The correct way is certainly not to let the database dictate your software design.
sam on October 22, 2004 10:00 AMI refer you to Paul Graham's "Why Arc Isn't Especially Object Oriented."
http://www.paulgraham.com/noop.html
Also, I spend a lot of time cleaning up behind people who set up grandiose object models that didn't work out. A lot of it is the Object-Relational mapping problem, aka the Vietnam of our (coding) generation:
http://www.neward.net/ted/weblog/index.jsp?date=20041003#1096871640048
Jeff Atwood on October 22, 2004 1:18 PMAlso, I spend a lot of time cleaning up behind people who set up grandiose object models that didn't work out.
Oh yeah? Any that I've ever seen? :-P The way you get rid of O-R Impedance issues... Or by using something like http://nurmagomedov.blogspot.com
Dagestan on March 14, 2008 5:55 AMI remember I went through a phase during my junior year of high school, in C++ class. (It was taught like straight C with iostream, BTW.)
I went through a phase of using for loops for everything. If I could do it with a while, I used a for. It was the most complex programming structure I fully understood at the time, so I used it like it was the pinnacle of all computer science up to that point.
The comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |