Myth: OOP is a proven general-purpose
technique
No actually OOP is a proved specific-purpose technique.
Myth: OOP models the real world better
OOP models objects really well
Myth: OOP makes programming more visual
Actually RAD tools make programming more visual. OOP is perfect for modeling component hierarchies.
Myth: OOP makes programming easier and faster
Not the first time. But it does make it easier to reuse code the second time.
Myth: OOP eliminates the complexity of "case" or "switch" statements
Yes with a properly designed class hierarchy.
Myth: Inheritance increases reuse
It can but so does aggregation. Actually aggregation or has-a relationships are easier to reuse. Unfortunately, Is-A relationships are easier to visualize but actually require more thought to implemement properly.
Myth: Most things fit nicely into hierarchical taxonomies
Actually most things can if they can if designed right.
Myth: Only OOP has automatic garbage collection
Not true.
Myth: Components can only be built with OOP
Again not true but it is easier and more natural to develop components in a OO framework.
Myth: Only OO databases can store large, multimedia data
Where does he get these?
Myth: OODBMS are overall faster than RDBMS
RDBMS have had longer to develop. And talk about improper models. Not all data should be modeled as relational.
Myth: C is the best procedural can get
Does he make these up?
Myth: Implementation changes significantly more often than interfaces
This is a design issue. If interfaces are imporperly designed then, yes of course, they'll change.
Myth: Procedural/Relational ties field types and sizes to the code more
I don't think so. OO or not if you don't properly encapsulate your variables you'll have trouble. It is just more natural to do this with OO.
Myth: Procedural/Relational programs cannot "factor" as well
This statement has nothing to do with OO. You can factor in p/r languages. You can always factor too little or too much.
OO is no silver bullet but it does a damn fine job until something better comes along.
--
BorlandInsider
Kylix - Delphi is just too cool to keep behind windows.
I wasn't that impressed with the article at all. I've worked with OO systems in big business and as a Tools Developer. The company I work for is a recognized leader WRT OO.
In my opinion there are three main aspects of OO:
1. Polymorphism
2. Encapsulation
3. Code-reuse
These are the pillers of OO. It is no secret that each of these can be accomplished in any computer language. It just won't be as easy or as natural as in a modern OO language.
In my experience, I have found that if your OO code isn't small and easy to understand the design was wrong. A properly designed OO program feels right. Incrememtatl changes tend to fit right in and is more solid. I can't imagine developing any of our products in a procedural language. Ugggh!
I bet that 2 letter code happened to be your state! BorlandInsider
Actually the only rule is that you can't play it the same way twice.
Myth: OOP is a proven general-purpose technique
No actually OOP is a proved specific-purpose technique.
Myth: OOP models the real world better
OOP models objects really well
Myth: OOP makes programming more visual
Actually RAD tools make programming more visual. OOP is perfect for modeling component hierarchies.
Myth: OOP makes programming easier and faster
Not the first time. But it does make it easier to reuse code the second time.
Myth: OOP eliminates the complexity of "case" or "switch" statements
Yes with a properly designed class hierarchy.
Myth: Inheritance increases reuse
It can but so does aggregation. Actually aggregation or has-a relationships are easier to reuse. Unfortunately, Is-A relationships are easier to visualize but actually require more thought to implemement properly.
Myth: Most things fit nicely into hierarchical taxonomies
Actually most things can if they can if designed right.
Myth: Only OOP has automatic garbage collection
Not true.
Myth: Components can only be built with OOP
Again not true but it is easier and more natural to develop components in a OO framework.
Myth: Only OO databases can store large, multimedia data
Where does he get these?
Myth: OODBMS are overall faster than RDBMS
RDBMS have had longer to develop. And talk about improper models. Not all data should be modeled as relational.
Myth: C is the best procedural can get
Does he make these up?
Myth: Implementation changes significantly more often than interfaces
This is a design issue. If interfaces are imporperly designed then, yes of course, they'll change.
Myth: Procedural/Relational ties field types and sizes to the code more
I don't think so. OO or not if you don't properly encapsulate your variables you'll have trouble. It is just more natural to do this with OO.
Myth: Procedural/Relational programs cannot "factor" as well
This statement has nothing to do with OO. You can factor in p/r languages. You can always factor too little or too much.
OO is no silver bullet but it does a damn fine job until something better comes along.
--
BorlandInsider
Kylix - Delphi is just too cool to keep behind windows.
I wasn't that impressed with the article at all. I've worked with OO systems in big business and as a Tools Developer. The company I work for is a recognized leader WRT OO.
In my opinion there are three main aspects of OO:
1. Polymorphism
2. Encapsulation
3. Code-reuse
These are the pillers of OO. It is no secret that each of these can be accomplished in any computer language. It just won't be as easy or as natural as in a modern OO language. In my experience, I have found that if your OO code isn't small and easy to understand the design was wrong. A properly designed OO program feels right. Incrememtatl changes tend to fit right in and is more solid. I can't imagine developing any of our products in a procedural language. Ugggh!
--
BorlandInsider
Kylix - Just too damn cool!
I am in the process of finishing up coding a TTabControl and TPageControl for project Kylix. Does this mean I can stop working and go home now?
-- I'm not a Linux guy but I play one at work. --
Oops.. Sorry bad formatting on the prev. submission. :-)
Haiku, Limericks
What more now can I say than
Where's Natalie Portman?
Haiku, Limericks
What more can I ask now than where's Natalie Portman?