CompuServe Messages

#ObjectOriented

    19-Sep-95 22:26:28
Sb: #48207-#ObjectOriented
Fm: Clay Spence 72713,2540
To: Peter Wade 100265,2740
Hi, Peter, PMFJI (Actually I'm hoping to learn something; I' haven't yet learned a language with support for OO programming.) >>There is a lot of talk about things being hidden and data only accessible to member functions but I don't see much advantage to this. If you are designing a program it is just common sense to be careful how you manipulate your data structures, why do you need some enforcement mechanism to control this? Especially since you are controlling this enforcement mechanism yourself.<< I would guess that it keeps you from having to design and remember rules that help you "be careful how you manipulate your data structures." The rules, to some extent, are designed for you. You get to design the classes, of course, so the rules aren't completely determined by the language. There are also cases in which it gives sensible structure. For example, I've written a neural net program in C. There are different kinds of neurons with different functions, and different sets of parameters for each kind. It makes sense to define a common interface that applies to each neuron type. I defined a structure that contains the variables that are common to any neuron type, a void pointer that code for each neuron type can initialize as it sees fit, and pointers to functions to implement the common functions, like "initialize yourself," "evaluate your output," etc. The higher-level code can just call the function pointed to in the neuron's structure without having to "know" which function to call for the neuron type. The higher-level code is simplified quite a lot by this, I think. If I had learned C++ I would hope that it would have been simpler. I don't see this as an enforcement mechanism, but perhaps I'm wrong. Clay