Hi Bob,
Good questions. I'm encouraged to see someone really trying to understand
this stuff instead of just using it!
As I understand it, OO practices state to create private member variables
and use these variables in your publicly accessible functions. This
requires the programmer to set the variables using the setters of the
class before calling the function.
It helps if you differentiate the term "Properties" from the term
"Functions." In a sense, a Property can actually BE 2 functions, one for
setting, and one for getting. It can actually be only one of these, hence
"read only" and "write only." A Property is actually a sort of "unholy
marriage" of a variable and one or 2 methods ("functions"). And, in fact, a
Property doesn't even have to relate directly to a private variable (or
"field" which is the term for a variable that is global to the class) at
all. Since a Property is actually one or two methods, these methods can do
virtually anything the designer wants them to. The only requirement is that
the getter must return a value of the type of the Property. So, for example,
let's talk about a property called "area" of a geometric figure. It could be
a "read only" property that calculates the area of the geometric figure, and
returns the value. In fact, there might not be a private "area" variable at
all, but simply the method that calculates it and returns it.
Hopefully, you are beginning to see the power of Properties at this point.
This requires the programmer to set the variables using the setters of the
class before calling the function. The problem that I see is that the
coder doesn't know the private variables needed by the public function
without viewing the actual code (since there is no signature, intellisense
tells them nothing).
Now we need to talk a bit about another OOP characteristic called
"Abstraction." You have a car. You start it by turning the key. So, let's
imagine a software car. It has a "read only" property called "Started." You
set "Started to true ("turning the key," so to speak), and the engine starts
up. What in fact has happened? The Started Set method is a function that
performs all the steps necessary to start the car. So, how much does the
driver (programmer) need to know about how the engine works? Nothing.
Nothing at all. All the driver needs to know is how to start the car.
Encapsulation hides all of the mechanism of the car's engine "under the
hood" in a "black box." Only the designer of the car actually knows how the
engine works. All you need is to get to work in the car. So, you don't need
to know how much air and gas to pump into the carbeurator, when to send the
spark, etc. All you need to do is start it and drive.
Okay, so now you're designing a car. How much do you need to know about it?
Well, if you build it entirely from scratch, you need to know quite a bit.
On the other hand, if you buy ready-made parts (alternator, transmission,
engine block, etc.), you are employing other objects in the design of your
car. You don't need to know how each of them works, only how they interface,
or interact, with the other parts of the car, and what their operating
characteristics are. This is simply an analogy for programming with the CLR.
The CLR is like a bunch of auto parts. How does a Socket operate internally?
Who cares? You can get one from the CLR and configure it to work in your car
(class).
If you understand these principles, you should be able to design your
classes so that, in essence, they are foolproof. As long as the programmer
that uses them knows how they interoperate in an application, they know
enough. The class itself should handle the rest.
So, the developer doesn't NEED to know anything about private members.
Private members are for the use of your class, not for the use of the
developer using it. Design your classes well, using the principles of OOP,
and your drivers will thank you for it!
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.