Аксессоры - это больше, чем поля. Другие уже указали на несколько важных отличий, и я собираюсь добавить еще одно.
Свойства принимают участие в интерфейсных классах. Например:
interface IPerson
{
string FirstName { get; set; }
string LastName { get; set; }
}
Этот интерфейс может быть удовлетворен несколькими способами. Например:
class Person: IPerson
{
private string _name;
public string FirstName
{
get
{
return _name ?? string.Empty;
}
set
{
if (value == null)
throw new System.ArgumentNullException("value");
_name = value;
}
}
...
}
В этой реализации мы защищаем как Personкласс от перехода в недопустимое состояние, так и вызывающий объект от получения значения NULL из неназначенного свойства.
Но мы могли продвинуть дизайн еще дальше. Например, интерфейс может не иметь дело с сеттером. Вполне правомерно сказать, что потребителей IPersonинтерфейса интересует только получение свойства, а не его установка:
interface IPerson
{
string FirstName { get; }
string LastName { get; }
}
Предыдущая реализация Personкласса удовлетворяет этому интерфейсу. Тот факт, что он позволяет вызывающей стороне также устанавливать свойства, не имеет смысла с точки зрения потребителей (которые потребляют IPerson). Дополнительная функциональность конкретной реализации учитывается, например, конструктором:
class PersonBuilder: IPersonBuilder
{
IPerson BuildPerson(IContext context)
{
Person person = new Person();
person.FirstName = context.GetFirstName();
person.LastName = context.GetLastName();
return person;
}
}
...
void Consumer(IPersonBuilder builder, IContext context)
{
IPerson person = builder.BuildPerson(context);
Console.WriteLine("{0} {1}", person.FirstName, person.LastName);
}
В этом коде потребитель не знает об установщиках свойств - это не его дело. Потребителю нужны только геттеры, а геттеры он получает из интерфейса, то есть из контракта.
Другой вполне допустимой реализацией IPersonбудет неизменяемый класс person и соответствующая фабрика person:
class Person: IPerson
{
public Person(string firstName, string lastName)
{
if (string.IsNullOrEmpty(firstName) || string.IsNullOrEmpty(lastName))
throw new System.ArgumentException();
this.FirstName = firstName;
this.LastName = lastName;
}
public string FirstName { get; private set; }
public string LastName { get; private set; }
}
...
class PersonFactory: IPersonFactory
{
public IPerson CreatePerson(string firstName, string lastName)
{
return new Person(firstName, lastName);
}
}
...
void Consumer(IPersonFactory factory)
{
IPerson person = factory.CreatePerson("John", "Doe");
Console.WriteLine("{0} {1}", person.FirstName, person.LastName);
}
В этом примере кода потребитель снова не знает, как заполнять свойства. Потребитель имеет дело только с геттерами, а конкретная реализация (и стоящая за ней бизнес-логика, например, тестирование, если имя пусто) предоставляется специализированным классам - разработчикам и фабрикам. Все эти операции с полями совершенно невозможны.