Как правильно определить свойства класса?
При определении нового класса в рамках проекта, какова корректная / лучшая практика для того, чтобы сделать так? В прошлом я создал классы, такие как:
public class MyClass
{
public string FirstName {get; set;}
public string LastName {get; set;}
}
Обычно я использовал бы класс, такой как это для создания наборов в рамках проекта.
Однако в то время как я продолжаю учиться и читать больше о c#, резком, я вижу примеры, где классы определяются как:
class MyClass //not set to public
{
private string _firstName; //first defined as fields
private string _lastName;
public string FirstName // then defined as properties
{
get { return _firstName; }
set { _firstName = value; }
}
public string LastName
{
get { return _lastName; }
set { _lastName = value; }
}
}
Действительно ли первый подход является неправильным в определении, или действительно ли это - принятая краткая версия в C#? Поскольку лучшая практика должна Вы всегда сначала определять класс с частными полями и затем определять их как использование свойств, добираются / набор до значения?
Я спрашиваю, потому что я выучился самостоятельно в C#, и я пытаюсь улучшиться и хорошо как лучше, чтобы понять надлежащий подход к разработке и некоторым образцам, и учебные руководства там просто указывают подходы без серьезного объяснения относительно того, почему один подход предпочтен (или должен быть сделан) по другому.
Заранее спасибо
4 ответа
Ваш первый пример:
public class MyClass
{
public string FirstName {get; set;}
public string LastName {get; set;}
}
конкретно Auto-Implemented Properties, представленный в c# 3.0. Ни один из форматов не является неправильным. Первый — это скорее «сокращение».
С более сложными типами иногда все еще полезно использовать старый стиль и предоставлять только определенные свойства или значения из закрытой переменной, такие как:
public class MyClass
{
private Dictionary<int, List<string>> _someInternalDictionary;
public int MyValuesCount
{
get
{
return _someInternalDictionary.Values.Count;
}
}
}
Грубый пример, но, надеюсь, вы понимаете мою идею.
Синтаксис сокращений (автоматически реализуемые свойства) в вашем первом примере был введен в C# 3.0, и до этого был недействителен. Компилятор фактически преобразует их в полную форму с обратными полями.
До C# 3.0 единственным правильным способом определения свойств было использование подкрепляющих полей.
Даже в C# 3.0, если вы хотите иметь какую-либо логику в ваших свойствах, вам нужно преобразовать их для использования подкрепляющих полей.
Короче говоря - для тупых свойств (тех, которые ничего не делают) используйте автоматические свойства. Они делают ваш код проще и легче для чтения, и их можно преобразовать.
Вы также можете использовать модификатор доступа для get и set...
public {ReturnType} MyProperty { {Access Modifier}get; {Access Modifier}set; }
И я предполагаю, что у вас уже есть знания о Access Modifier.
Два класса, которые у вас есть, на практике идентичны по функциям и возможностям.
Назначение синтаксиса автоматических свойств (первый класс) состоит в том, чтобы дать вам быстрый способ объявить то, что по сути совпадает со вторым классом, который вы показываете.
Я бы придерживался первой версии до тех пор, пока вам не понадобится добавить код в метод получения или установки (например, проверка нового значения свойства).
Назначение синтаксиса автоматического свойства двоякое, он был частично добавлен чтобы упростить Linq, и частично добавлен, чтобы упростить декларацию свойств, а не общедоступных полей.
Если вы объявляете класс с использованием автоматических свойств (опять же, первая версия), тогда все другие сборки, скомпилированные с вашим кодом, будут знать, что ваш класс объявляет эти вещи как свойства, а не как поля. Если позже вы решите, что вам нужно добавить код, например проверку, эти другие сборки не нужно перекомпилировать, поскольку они все равно находят свойства.