Basic OO question...

[Bob Morvay]

I am trying to determine how far I should go in encapsulating data. 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. 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).
Furthermore, overloading becomes troublesome. Maybe I am over-engineering
the use of the private members in a class in regards to methods. Should
methods always have a signature and when should we use private members. I
am probably confusing myself :)

[Patrice]

Not sure to understand. Why would the coder need to know what are the
private members ? There is no need for him to know...
Also it looks like there is some confusion between methods, singatures and
the like.

It looks like the principle you are referring two is to expose "values" as
"properties" rather than "public fields".

The reason for this is that the former allows to run addtional check (as
your code runs) while you would have no control on the later. Even if you
does nothing for now, it would likely break later (as previously compiled
code would use an assignment where it would be know a call to the "setter").

For these reasons it is considered best practice to access to "values"
through properties (set/get) rather than exposing directly the value as a
"field".

(I'm not even sure to use the correct words myself ;-)

Patrice

--

"Bob Morvay" <[e-mail]> a écrit dans le message de
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am over-engineering
the use of the private members in a class in regards to methods. Should
methods always have a signature and when should we use private members. I
am probably confusing myself :)

[Karl Seguin]

You use private member fields for data which describes the object. You use
these private fields within your public functions when the function alters
the behaviour/data of your object. If you aren't clear whether to use
private fields w/public properties vs function parameters, something's
wrong. Typically they two aren't interchangable so I'm not sure why you are
confused. Private members exist for the duration of the object (ie as long
as you hold a reference to it). Parameters that you pass into a function
are lost at the end of the function call (unless you store there somewhere
yourself).

let's try another way, function parameters are typically used by said
function and only said function...they are scopped to the function and no
other parts of the class (they can be used by other parts of the calling
code of course). Private members are scopped to the entire class and hold
data for use by the entire class.

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)

[Yunus Emre ALPÖZEN [MCAD.NET]]

Hi Bob,

To access private variables you can use public/protected properties you need
not to use functions in C# and VB.NET. J# doesnot support properties
directly and C++.NET properties are implemented with using functions. My
advice you take a look at VS.NET 2005 for promoting functions and
properties. I think it does what u need, if i fully understand what u mean.

--

Thanks,
Yunus Emre ALPÖZEN
BSc, MCAD.NET

"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)

[Kevin Spencer]

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.

"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)

[Kevin Spencer]

Correction: When I spoke of the "Started" property of the car illustration,
I said "read only." I should have said "write only."

--

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)

[Bob Morvay]

I think I get the point about abstraction but I have to ask the question how
does one know to use a key to start the car. In technical terms this may be
to execute the setter for a key that will be used to start the car. The car
method would not have any parameters but will expect that a key is ready for
use. Developers will need to know that they need a key to start the car.
How do you expose to the developer that he needs to use a key in order to
execute the start process of a car without exposing the start process?
Sheesh, I hope I haven't overdone the car example. This can be applied to
any method of a type of class. In regards to overloading, doesn't
signature-less methods really mess with overloading. Especially if the
method is using private member variables that get set outside of the method
with public properties?
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

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.

"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)

[Kevin Spencer]

Hi Bob,

Okay, the car is the class, not a method. Abstraction means that you can
treat the class as if it were a "real world" kind of device. So, in my
analogy, the car is a class.

So, we have a class called "car" and a property (write only) called
"Started." All you need to do is write documentation that tells the
developer that to "start" the "car class" he sets the "Started" property to
true. Again, using my analogy, the "Started" property IS the key. It is what
starts and stops the car's engine. When you set the property to false (not
Started), the property's set method performs all the steps to shut the
engine down, such as cutting off the air flow and gas flow, stopping the
spark, etc. You could also make the Started property read-write, use a
private field called _Started that is set in the setter, and use the get
method to find out if the car is started by returning the value of _Started.
I was trying to keep it simple (for a "Start" ;-)).

Overloading is another topic altogether, and has to do more with Inheritance
than Encapsulation. I'd be happy to discuss it, but it is important to have
these concepts down pat first! I will say that it is important to design
classes well in order to make the best use of them. Encapsulation can be a
force for great good or evil. It is also important to document them well if
you expect people to use them effectively and/or extend them. Of course,
anyone can break just about any software they use if they are either clever
and/or stupid enough!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

"Bob Morvay" <[e-mail]> wrote in message
news:%2******************@TK2MSFTNGP14.phx.gbl...

I think I get the point about abstraction but I have to ask the question
how does one know to use a key to start the car. In technical terms this
may be to execute the setter for a key that will be used to start the car.
The car method would not have any parameters but will expect that a key is
ready for use. Developers will need to know that they need a key to start
the car. How do you expose to the developer that he needs to use a key in
order to execute the start process of a car without exposing the start
process? Sheesh, I hope I haven't overdone the car example. This can be
applied to any method of a type of class. In regards to overloading,
doesn't signature-less methods really mess with overloading. Especially if
the method is using private member variables that get set outside of the
method with public properties?
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

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.

"Bob Morvay" <[e-mail]> wrote in message
news:O8*************@TK2MSFTNGP09.phx.gbl...

I am trying to determine how far I should go in encapsulating data. 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. 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). Furthermore, overloading becomes troublesome. Maybe I am
over-engineering the use of the private members in a class in regards to
methods. Should methods always have a signature and when should we use
private members. I am probably confusing myself :)