I was perusing a CLR newsgroup the other day and stumbled across a post by Bob Grommes. It goes as thus:
“Actually, it's important to distinguish between classes and objects. It's one of the weak points in people's thinking and communicating about object technology. A class is a blueprint, an object is an instance of the blueprint. Confusing classes and objects is like confusing the blueprint for a house with one of the houses built from it.
It may seem like semantic nit-picking but in my experience, nothing encourages sloppy thinking like mixing up the two terms. It's important to keep them straight in your head, and in other people's heads. In fact I've come to favor the term "instance" or "instance of" rather than "object" for this reason. It doesn't help that for years, marketroids have said "object" when they should have said "class" or "component" or "UI widget".
Regarding structs vs classes, there is a conventional wisdom in some circles, bordering on an urban legend, that structs are more efficient than classes because they don't go on the heap, they go on the stack. In truth, that is both a virtue and a vice from a performance standpoint depending upon what you are attempting to accomplish. And there are considerations other than performance -- things like clarity and elegance in your code, maintainability and so forth, that can trump performance more often than not. Especially since on modern hardware and operating systems, performance is often nowhere near the real-world factor that it's imagined to be. Just because some code snippet runs three times faster doesn't mean that will be perceptible to the ultimate user.
I'm with Jon on this one -- be guided mainly by the semantics required in a particular situation. Don't invest tremendous amounts of effort or concoct idiosyncratic designs based on performance concerns, unless you can demonstrate real-world performance issues and have truly ascertained where the bottleneck is. If you are concerned going into the design phase that you may be dealing with a performance-critical design decision, prototype some proof of concept code to see how much of a difference you're really looking at between two approaches. I have been surprised every time I've done this to find that my performance assumptions did not stand up to the real world.“
Personally, I can't overstate how I much I feel that the loose usage of semantics in our industry is affecting the quality of software. I believe it leads to a lot of misconceptions. Hopefully, I'll be able to post on this later.
Print | posted on Thursday, November 03, 2005 6:18 AM