Newbie Q - why use these?

  • Thread starter Thread starter Peter Morris
  • Start date Start date
P

Peter Morris

Hi, just learning C# from a book.

I've learned *how* to use properties, but not why. What are they
used for? Why have a private attribute that you can access
through properties? If you want it to be accessible, why not
just make it public? What is the advantage of using a property?


Also, why use delegates? This seems a particularly complex and
roundabout way of writing a method. Also the code for the method
is defined outside the class, doesn't this defeat the point of
encapsulation? Why would you do it this way?


--
_______________________
/_____________________(_)
| _____________________ email to
| | |__________________(_) Peter_Morris_1 at
| |/____________________ btinternet dot com
|_____________________(_)
 
1. Properties act as accessors. What you put underneath these properties is
up to you. Not always will you have a property have a direct relationship
with one private member.

For example, you can have a Rectangle class, which can have private members
length and breadth. But you can have a property "Area" that needn't have a
new variable.

2. Delegates are not methods. Delegates are "call-backs." Call backs (if
they want to do anything useful) usually lie outside the class
implementation.

-vJ
 
Peter Morris said:
Hi, just learning C# from a book.

I've learned *how* to use properties, but not why. What are they
used for? Why have a private attribute that you can access
through properties? If you want it to be accessible, why not
just make it public? What is the advantage of using a property?
Click to expand...
Properties offer a few advantages:
1) they can be read only, by using only a get accessor.
2) they can perform complicated verification or lookup logic, like loading a
value from a database on the first access, or calculating dynamic data when
accessed.
3) They allow for greater binary compatibility. If you are forced to make a
change in how a property works, pre-compiled code can still access the
property. Whereas converting a field to a property is a binary breaking
change.
Also, why use delegates? This seems a particularly complex and
roundabout way of writing a method. Also the code for the method
is defined outside the class, doesn't this defeat the point of
encapsulation? Why would you do it this way?
Click to expand...
You don't actually write methods as delegates, a delegate is an object that
refers to a given method(on a given object). When you create a delegate, it
references your method, then this delegate can be passed around and called
by code outside of your object in a standard manner(based on the delegate
type), providing a simpler method than passing interface references, as java
does, for example.
 
Property semantics are really nice for the client code:

int len = strName.Length;

But unlike public data fields, a property implementation may execute code.
Does String.Length's implementation measure the string when you access this
property, or is that value cached? It doesn't matter: it appears to the
client at the correct level of abstraction, as just a value. The
implementation of String.Length can change, but the client code is insulated
from this and will continue to work.

Also we can have read-only and write-only properties, which could not be
done with plain public data fields.

Delegates have the distinction of being described confusingly in many places
and by many people. Amit Kalani gives the best definition in his 70-316
book I have seen outside of the specification: "A delegate is a special
class whose object is capable of storing references to methods of a
particular signature."

I think you are missing the purpose of delegates, so I'm a little curious
which C# book you are reading. They are not just another way to write a
method. Delegates give us a way of writing some code (let's say, code A)
that calls some method of a particular signature, even though it is code B
that will hand-off at run-time *which* exact method code A will be calling.

The standard example is that of a GUI button. The button itself is coded,
by a GUI library programmer in Redmond, such that it can inform curious
listeners when it is pressed. This allows the application programmer in
Israel, who wants to use that GUI library to place some buttons on his new
form, to "sign up" his form as a listener and respond to any button presses.

Once you understand when and why we need things like delegates (just as we
needed callbacks and function pointers in other programming environments), I
would further like to give a few hints for understanding delegates and
events: (1) A delegate object is itself a *linked list* -- thus the
slightly magical += semantics are for "adding" the right-hand delegate
linked-list to the left-hand delegate linked list. (2) Usually *an event is
just a delegate instance* with special status and limitations about who can
do what with it (e.g., a client class may sign up for another class's event,
but it cannot invoke it). Notice that when your book gives a simple example
of coding an event, you can remove the word "event" from the code and it
still compiles and runs as before!
 
What is the advantage of using a property?
Biggest advantage for me personally is - breakpoints. In the 'set' of my
property I can set a breakpoint when I want to find out when something is
changed (tracking down bugs etc).
Cant easily do that if the field in question is a 'naked' public int or
whatever.
 
Back
Top