An important aspect of Class design is controlling access to Properties: there may well be many cases where you do want
any user (consumer) of your Class to be able to both set, and get, the value of Properties.
But, often, it's the case you want to control
setting the Property, making sure it can only be changed through explicitly calling a method of the Class. Why ? Well, there may be complex dependencies on the value of the Property in different parts of your code, among other reasons. You may wish the Property to function, effectively, as a read-only Property while still allowing one point of access to set the value.
Using the "automatic" get/set facilities that C# 3.0 brought us, it's very easy to write a Property with a public getter and a private setter. If you are unfamiliar with auto-implemented Properties see: [
^].
An example:
namespace OOP
{
public enum FurColor { black, white, brown };
public interface ILion
{
void ChangeFurColor(FurColor theFurColor);
}
public class Lion: ILion
{
public FurColor CurrentFurColor { get; private set; }
public void ChangeFurColor(FurColor newFurColor)
{
CurrentFurColor = newFurColor;
}
}
}
It has been said (I forget where I read it) that Properties are used to provide the
interface to Classes: that's in contrast to the role of variables (fields) which are parts of the
implementation of a Class.
Finally, I'd like to state my strong belief that using the
same names for Classes, Properties, variables, etc., or even using the same names with different letter-case is a recipe for disaster ... even though the .NET compiler may bless you !
Think about how "readable" your code is going to be when you look at it a year after you wrote it: when you see an enum named 'FurColor, a Property named 'furcolor, and, in the parameter list of a method, a parameter named 'furcolor. Better yet, think about how when someone else has to maintain/change your code (because you are rich and famous), they will be able to understand the intent of each line of your code :)
At the risk of sounding "preachy," I would encourage you to develop a habit of creating "strong" descriptive names in your code
now, and developing a consistent pattern of naming that makes your code easy to understand, that helps you recognize ... visually ... what the differences are between class, struct, enum, variable, method, property, parameter, etc.