Object oriented code is not inherently more maintanable than non-OO code.
Definitely true, IMHO
It's just easier to structure in a maintanable way.
I'm afraid I don't agree here. In my experience I have found that OO code actually tends to be brittle. As long as the changes that occur are those that are anticipated and designed for, things are OK. When the requested changes cross the boundaries, things tend to get messy quick. As a result, "good" OO design requires that the application programer be part fortune teller. The lifetime of the program is directly related to how well he/she/it predicts what will have to change.
I was involved in an Air Traffic Control research project (all OO, Smalltalk in fact) several years back and experienced much of this first hand. We were building a prototype interface to explore new interaction techinques for the controllers. One group was designing the interface interaction, and I and several students were designing and implementing the code to realize the interface. The eye opener for me was the perception of changes to the interface dialog by those designing the interface. Several requests that they considered to be easy would have required massive rewrites to implement (and consequently were not implemented), because they were unanticipated. Several other requests they considered to be difficult were implemented in hours. Thier perception of the structure of the system differed from the actual implementation. Where the perceived structure of the system matched, changes perceived as difficult were difficult and easy changes were easy.
In my current position, I deal with legacy systems, many of which are 20+ years old. Contrary to popular perception, many of these systems are well structured with tight interfaces (interfaces doesn't mean OO). The code has evolved over many years adapting to changing requirements as needed. I wonder if the OO based code produced by myself, my graduate students, and my colleagues will ever approach this life span. Or will they be discarded and reimplemented because the environment has changed so much that they cannot evolve to adapt?
There is a lot of OO hype. But the only true test for durability is time. A friend of mine at a large software company is tracking statistics of internal projects done with OO vs projects done with more conventional techniques. It will be interesting to see how OO fairs over the long term. After all, those programmers writing the original banking systems in the late 60's early 70's could have hardly imagined a world of bank machines, direct payment machines, and instant internet loan approvals. What changes will current programs, including operating systems, have to face over the next 4 decades?
Slashdot Mirror
Object oriented code is not inherently more maintanable than non-OO code.
Definitely true, IMHO
It's just easier to structure in a maintanable way.
I'm afraid I don't agree here. In my experience I have found that OO code actually tends to be brittle. As long as the changes that occur are those that are anticipated and designed for, things are OK. When the requested changes cross the boundaries, things tend to get messy quick. As a result, "good" OO design requires that the application programer be part fortune teller. The lifetime of the program is directly related to how well he/she/it predicts what will have to change.
I was involved in an Air Traffic Control research project (all OO, Smalltalk in fact) several years back and experienced much of this first hand. We were building a prototype interface to explore new interaction techinques for the controllers. One group was designing the interface interaction, and I and several students were designing and implementing the code to realize the interface. The eye opener for me was the perception of changes to the interface dialog by those designing the interface. Several requests that they considered to be easy would have required massive rewrites to implement (and consequently were not implemented), because they were unanticipated. Several other requests they considered to be difficult were implemented in hours. Thier perception of the structure of the system differed from the actual implementation. Where the perceived structure of the system matched, changes perceived as difficult were difficult and easy changes were easy.
In my current position, I deal with legacy systems, many of which are 20+ years old. Contrary to popular perception, many of these systems are well structured with tight interfaces (interfaces doesn't mean OO). The code has evolved over many years adapting to changing requirements as needed. I wonder if the OO based code produced by myself, my graduate students, and my colleagues will ever approach this life span. Or will they be discarded and reimplemented because the environment has changed so much that they cannot evolve to adapt?
There is a lot of OO hype. But the only true test for durability is time. A friend of mine at a large software company is tracking statistics of internal projects done with OO vs projects done with more conventional techniques. It will be interesting to see how OO fairs over the long term. After all, those programmers writing the original banking systems in the late 60's early 70's could have hardly imagined a world of bank machines, direct payment machines, and instant internet loan approvals. What changes will current programs, including operating systems, have to face over the next 4 decades?