TITLE: rationale for OO techniques (Newsgroups: comp.object,comp.lang.c++.moderated, 17 Oct 98) [] denote third party comments, not part of the original dialog. ODOWD: Robert O'Dowd >Using objects usually requires much more >effort to be expended in analysis and design, before you arrive at the >point of cutting code. MARTIN: "Robert C. Martin" That depends upon how you do it. I prefer to cut code as part of the analysis and design process. ODOWD: >In practice I have found that an object oriented >design takes at least twice as long to get to the point where it is >implemented. MARTIN: I can't vouch for the number, but I agree that a well thought through OO design will take longer than just pasting a bunch of code together. ODOWD: >This all means, on average, that getting the first product out the door >takes longer with OO techniques. [ TRIBBLE: David R Tribble Depends on how much your program does. If it can benefit from third-party libraries to do a lot of the redundant or more complex work, the time to market may be shorter. ] MARTIN: Probably. This is especially true if there are high level libraries that can help you. On the other hand, if you have solved similar problems before, and have accumulated a reasonable amount of reusable library code, then the time to market can be dramatically shortened. ODOWD: >The value of OO comes in with reuse >(extending an existing design, reusing the same design in another >application, etc). MARTIN: This is correct, but does not go far enough. The value of OO comes from its ability to decouple software. It is that decoupling that enables reuse. However that decoupling also makes the software more flexible and resilient so that changing requirements do not unravel the existing design. [ TRIBBLE: Yes. The value of the resiliency that the decoupling brings you is also that your code is less brittle and exhibits less low-level bugs such as memory leaks and memory corruption. Data structure reclamation, pointer errors, and memory corruption are a lot less likely to happen when the techniques of data hiding and strict type-checking are employed. ] ODOWD: >If you do not need to worry about reuse, then OO >costs more than it gives. MARTIN: If you do not need to worry about reuse, flexibility, or decreasing the long term cost of maintenance; and if you do not already have a respository of reusable components, then OO costs more than it gives. [ TRIBBLE: Not necessarily. OO can give you better code that behaves more reliably, which reduces costs far more in the long run (during the whole lifetime of the code) that the cost of developing it. As Martin alluded, maintenance costs can far outweight development costs over a product's lifetime. Decoupling can give you more maintainable code because object classes partition the code into more manageable pieces. The down side to this argument is that your maintenance programmers have to be more OO-literate, or else your developers are just writing code that the maintainers find obscure and complex. ]