A field is a variable of any time declared in the class. The fields are usually private, which means that they cannot be accessed from outside the class.
Field could be exposed by a public property - however, it's not recommended in every case.
Exposing a field by setter and getter might lead to an unwanted state of the system - that's because it's harder to keep control over what is assigned to a field.
Let's take the Address class as an example. If we expose just properties - we can write whatever we want into the zip code.
public class Address
{
// Other properties
public string ZipCode { get; set; }
}
static void Main(string args[])
{
var address = new Address();
address.ZipCode = "I can type whatever I want here!";
}
Let's refactor it and see if we can do it better.
public class Address
{
// Other parts of Address class
private string _zipCode;
public void SetZipCode(string zipCode)
{
if(!string.IsNullOrEmpty(zipCode) && zipCode.IsValidZipCodeFormat())
_zipCode = zipCode;
else throw new ArgumentException(nameof(zipCode));
}
}
static void Main(string args[])
{
var address = new Address();
address.SetZipCode("81-840");
address.SetZipCode("abcdefgh"); // throws Argument Exception
// Not possible anymore
// address.ZipCode = "I can type whatever I want here!";
}
We encapsulated the knowledge of how to set the zip code and what rules have to be fulfilled within the SetZipCode method. Now, anyone calling this method will have to fulfill those rules.
Summary
Don't get me wrong, properties are awesome and they have their place. But I often see them misused and they're often a reason for lacking encapsulation. If possible - limit the possibility to modify your data with carefully crafted methods.
Join dotnetcoreschool.com and learn C#
Top comments (4)
In your example you use default property setter and getter but you can define your own property accessors for this purpose which is much cleaner.
docs.microsoft.com/en-us/dotnet/cs...
Hey Nicolas, you're totally right.
That's another way to do it :) Thanks for sharing!
It is the idiomatic way to do it.
Yup, it's a little bit click-bait'ish... 😅
"In case the ZIP Code is required in more than one place and circumstances allow it, I like to use a separate Struct instead of just a String. That way I can keep the entire ZIP logic and string formatting in one place and reuse it wherever I need it." - Great example. I would use something similar to struct - Value Object. But that's for another topic :)
thanks for comment, Sebastian!