Surely that explanation applies to modules in general - not just of the OO flavour?
Modules are by nature designed to facilitate code reuse and naturally they (should) come with their own documentation.
How OO lends to a "fairly rigid testing structure" I'm not sure as, again, this seems to come under the heading of modules in general.
--- Jay
All code is untested unless otherwise stated.
| [reply] |
That is generally true of functional programming as well, no? I feel OOP is great when you can seperate you can draw clear lines between your various forms of data and behaviorrs to be taken out on them. Parsers for instance, do not easily fall into this, as you might wind up witha single class called "parser" and a bunch of supporting functions.
My counter example, is when I thought doing tests for a theory related project, graph colouring, would be silly to do as OOP. But if I can pass the different cases around as objects and the types of tests as classes, then it's a lot cleaner, to pass around the data and have functions available to call on them. Im not able to mix up a behavior with a piece of data.
-s
----
Then B.I. said, "Hov' remind yourself
nobody built like you, you designed yourself"
| [reply] |
