Often you'll want to have more than one method with the same name. The most common example of this is to have more than one constructor with the same name, which allows you to create the object with different parameters. For example, if you were creating a Time object, you might have circumstances where you want to create the Time object by passing in the date, hours, minutes, and seconds. Other times, you might want to create a Time object by passing in an existing Time object. Still other times, you might want to pass in just a date, without hours and minutes. Overloading the constructor allows you to provide these various options.
It would be convenient also to allow the client to create a new Time object by passing in year, month, date, hour, minute, and second values. Some clients might prefer one or the other constructor; you can provide both and the client can decide which better fits the situation.
In order to overload your constructor, you must make sure that each constructor has a unique signature. The signature of a method is composed of its name and its parameter list. Two methods differ in their signatures if they have different names or different parameter lists. Parameter lists can differ by having different numbers or types of parameters.
Encapsulating Data with Properties :
It is generally desirable to designate the member variables of a class as private. This means that only member methods of that class can access their value. You make member variables private to support data hiding, which is part of the encapsulation of a class.
Object-oriented programmers are told that member variables should be private. That is fine, but how do you provide access to this data to your clients? The answer for C# programmers is properties. Properties allow clients to access class state as if they were accessing member fields directly, while actually implementing that access through a class method.
This is ideal. The client wants direct access to the state of the object. The class designer, however, wants to hide the internal state of the class in class fields and provide indirect access through a method. The property provides both: the illusion of direct access for the client and the reality of indirect access for the class developer.
By decoupling the class state from the method that accesses that state, the designer is free to change the internal state of the object as needed. When the Time class is first created, the Hour value might be stored as a member variable. When the class is redesigned, the Hour value might be computed or retrieved from a database. If the client had direct access to the original Hour member variable, the change to computing the value would break the client. By decoupling and forcing the client to go through a property, the Time class can change how it manages its internal state without breaking client code.
In short, properties provide the data hiding required by good object-oriented design.
Returning Multiple Values
Methods can return only a single value. But this isn't always convenient. Let's return to the Time class. It would be great to create a GetTime() method to return the hour, minutes, and seconds. You can't return all three of these as return values, but perhaps you can pass in three parameters, let the GetTime() method modify the parameters, and then examine the result in the calling method, in this case Run().
Passing by Value and by Reference
When you pass a value type (such as an int) into a method, a copy is made. When you make changes to the parameter, you make changes to the copy. Back in the Run() method, the original integer variables, theHour, theMinute, and theSecond are unaffected by the changes made in GetTime().
What you need is a way to pass in the integer parameters by reference. When you pass an object by reference, no copy is made. A reference to the original variable is passed in. Thus when you make changes in GetTime(), the changes are also made to the original variables in Run().
related postDAY 1 MICROSOFT DOT NET FRAME WORK
DAY 2 MICROSOFT DOT NET BASE CLASS LIBRARY
DAY 3 MICROSOFT DOT NET CLASSES AND STRECTURES
DAY 4 METHODS IN FRAME WORK
DAY 5 INPUT VALIDATIONS IN DOT NET PART ONE
DAY 6 INPUT VALIDATIONS IN DOT NET PART TWO
DAY 7 DATA TYPES IN DOT NET
DAY 8 DATA TYPES IN DOT NET PART TWO
DAY 9 IMPLEMENTING PROPERTIES IN DOT NET
DAY 10 DELEGATES AND EVENTS
DAY 11 OOPS INTRODUCTION
DAY 12 POLYMORPHISM
DAY 13 INHERITANCE AND POLYMORPHISM
DAY 14 EBUGGING TOOLS IN DOT NET
DAY 15 DEBUG AND TRACE IN CLASSES
DAY 16 UNIT TEST PLAN
DAY 17 EXCEPTIONS IN VISUAL STUDIO
DAY 19 ADO.NET INTRODUCTION
DAY 20 DATA ACCESSING IN DOT NET
DAY 21 DATA BASE OBJECTS