CompuServe Thread

>The other way it gets a bad rap is when it it partially implemented late in the >development cycle. This is true of "any sanity added to any chaos", but yes, it's an easy politics "see, see, I told you". Always sad in the real world. > What most people fail to appreciate is the OO starts with >OOA (analyis) OOR (requirements) OOD (design) OOS (specification) >before coding even starts. Absolutely. >The entire system or localized sub-system has to be objectified in >total – that is have all its ojects, methods and messages defined – before >coding starts, otherwise you get code like you describe. This is pushing it, and in fact, in many cases impractical. When possible though, yes, this is the route. Of course, when not 100% possible, the more malleable and expressable route needs to be taken. > But that always results, regardless of the paradigm in use if the paradigm >is not followed from analysis through final testing. IOW, forethought, discipline, plans, and goals. Sure. >It is not a natural outcome of OO as you suggest. I'm less concerned about whether it's a natural or unnatural outcome. I know it's possible in some cases. What needs to be asked in those cases is whether things were taken to the extreme?, whether the thing is just a monster anyway, what the design and coding team were like, etc, and of course what the result would have been under another approach. Anyway, my major objection to the suggestion was that it was a blanket statement. We're talking about modelling something under certain constraints. As such, the suggestion doesn't fly in general.