Possible Duplicate:
Wh开发者_如何学编程y use getters and setters?
Why use getters and setters?
To limit access to an internal state of an object.
Consider the classic example of a class of geometric shapes. Say, a Circle object. When you set the radius, you may want to automatically calculate the area (which would be a read-only property)
class Circle
{
float radius;
public float Radius
{
get { return radius; }
set { radius = value; area = Math.Pi * radius * radius;}
}
float area;
float Area
{
get { return area;}
}
}
If you allowed direct access to the "radius" data member, you could not update area
when it changed. Further, if you allowed direct access to area
, users could change it willy-nilly without regard for radius
.
To encapsulate, and that way you make how you store data within your class an implementation detail. If your class has a getter/setter:
private string _mystring = string.Empty;
public string SomeValue
{
get
{
return _mystring;
}
}
That allows you to change how you manage "SomeValue" in the future. For example, you may decide that rather than storing it in a string, it's actually going to be a Guid under the hood. Now you could go for:
private Guid _myguid= Guid.NewGuid();
public string SomeValue
{
get
{
return _myguid.ToString();
}
}
Anywhere that your class is used and the "SomeValue" property is accessed will remain unbroken this way.
Validation
You can also validate the value passed in as well, so in another example:
private string _mystring = "My Value";
public string SomeValue
{
get
{
return _mystring;
}
set
{
if (string.IsNullOrEmpty(value))
{
throw new InvalidArgumentException();
}
else
{
_myString = value;
}
}
}
To ensure that the stored string is never set to a null/empty string
to encapsulate.
If you make a field private and set up a getter and a setter to access it, then all other code has to go through those methods to get at that data. Then, you have more control.
- You can make it read-only (no setter).
- You can validate input in the setter, and reject it if it's not acceptable.
- You can instantiate the object only when needed, when the getter is first called.
- You can change how it all works later.
You get these same benefits within the class, too, if you strictly use the getter and setter to access the field. So for many people it's something they do all the time.
Getters and setters initially don't look so great because they seem like a lot of extra typing. But IDEs like Eclipse can automatically make getters and setters for you, if you like. Languages like Objective-C and Ruby can do that too, using abbreviated syntax. C# can wrap getters and setters in "properties", which are used in code just like fields, but under the hood it calls the getter and setter that you write.
So there are a lot of reasons to use getters and setters, and many facilities to make it less painful.
One reason is to provide a more uniform interface to an object in some languages- you no longer have to deal with the syntactic difference between fields and methods; you always deal with methods.
A second reason is that you hide the implementation of the object, allowing you to change it internally without affecting its clients. A classic example is one of coordinates - if you have a coordinate represented via cartesian coordinates, and switch the internal representation to polar, if you used getters and setters your program would still work even though the x and y fields are gone. This also allows you to use polymorphism - two objects representing the same abstraction, but each with a different implementation of their state.
Accessing state via methods also lets you add things like synchronization.
精彩评论