Автоматичні властивості C # 3.0 - корисні чи ні? [зачинено]

Примітка. Це було опубліковано, коли я починав C #. Маючи знання про 2014 рік, я можу по-справжньому сказати, що автоматичні властивості є одними з найкращих речей, які коли-небудь траплялися з мовою C #.

Мене використовують для створення своїх властивостей у C # за допомогою приватного та загальнодоступного поля:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Тепер із .NET 3.0 ми отримали автоматичні властивості:

public string Title { get; set; }

Я знаю, що це скоріше філософські / суб'єктивні питання, але чи є причина використовувати ці автовластивості, крім збереження п'яти рядків коду для кожного поля? Моя особиста прихильність полягає в тому, що ці властивості приховують від мене речі, і я не є великим прихильником чорної магії.

Насправді приховане приватне поле навіть не відображається у відладчику, що добре, враховуючи той факт, що функції get / set функції нічого не роблять. Але коли я хочу реально реалізувати певну логіку геттера / сетера, я все одно повинен використовувати приватну / публічну пару.

Я бачу вигоду в тому, що я зберігаю багато коду (один проти шести рядків), не втрачаючи можливості змінити логіку геттера / сеттера пізніше, але потім знову вже можу це зробити, просто оголосивши публічне поле "Публічний заголовок рядка" без потреба {get; набір; } блок, таким чином навіть економлячи більше коду.

Отже, чого я тут пропускаю? Чому хтось насправді хотів би використовувати авто-властивості?

Ми постійно їх використовуємо в Stack Overflow.

Можливо, вам також буде цікава дискусія " Властивості проти загальнодоступних змінних" . ІМХО - це насправді, на що це реакція, і для цього це чудово.

Так, це просто зберігає код. Милі легше читати, коли ти навантажуєш їх. Вони швидше писати і простіші в обслуговуванні. Збереження коду - це завжди хороша мета.

Ви можете встановити різні сфери застосування:

public string PropertyName { get; private set; }

Так що властивість можна змінити лише всередині класу. Це насправді незмінне, оскільки ви все одно можете отримати доступ до приватного сетера через роздуми.

На C # 6 ви також можете створити справжні readonlyвластивості - тобто незмінні властивості, які не можна змінити поза конструктором:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Під час компіляції, який стане:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

У незмінних класах з великою кількістю членів це економить багато зайвого коду.

Три великих недоліки використання полів замість властивостей:

1. Ви не можете прив’язати дані до поля, тоді як ви можете до власності
2. Якщо ви почнете використовувати поле, ви не зможете пізніше (легко) змінити їх у властивість
3. Є деякі атрибути, які ви можете додати до властивості, яку ви не можете додати до поля

Я особисто люблю авто-властивості. Що не так із збереженням рядків коду? Якщо ви хочете робити речі в геттерах або сетерах, згодом не виникає проблем перетворити їх у звичайні властивості.

Як ви сказали, ви можете використовувати поля, і якщо ви хочете пізніше додати логіку до них, перетворите їх у властивості. Але це може створити проблеми при використанні рефлексії (а можливо, і в іншому місці?).

Також властивості дозволяють встановлювати різні рівні доступу для геттера та сеттера, які ви не можете зробити з полем.

Я думаю, це те саме, що і ключове слово var. Справа в особистих уподобаннях.

Від Bjarne Stroustrup, творець C ++:

Мені особливо не подобаються заняття з великою кількістю функцій отримання та встановлення. Це часто свідчить про те, що це не повинно було бути в першу чергу класом. Це просто структура даних. І якщо це справді структура даних, зробіть це структурою даних.

А ви знаєте що? Він правий. Як часто ви просто загортаєте приватні поля в get і set, не роблячи насправді нічого в межах get / set, просто тому, що це "об'єктно-орієнтована" річ. Це вирішення проблеми Microsoft; вони в основному є загальнодоступними полями, до яких можна зв’язатись.

Одне, що, здається, ніхто не згадував - це те, як, наприклад, автоматичні властивості не корисні для незмінних об'єктів (як правило, незмінних структур). Тому що для цього вам справді слід зробити:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(де поле ініціалізується в конструкторі через пройдений параметр, а потім читається лише.)

Таким чином, це має переваги перед простим get/ private setавтовластивістю.

Я завжди створюю властивості замість загальнодоступних полів, оскільки ви можете використовувати властивості у визначенні інтерфейсу, ви не можете використовувати загальнодоступні поля у визначенні інтерфейсу.

Авто-властивості - це настільки ж чорна магія, як і все, що в C #. Коли ви думаєте про це з точки зору складання до IL, а не для розширення до звичайного властивості C #, спочатку це набагато менше чорної магії, ніж безліч інших мовних конструкцій.

Я постійно використовую автоматичні властивості. Перед C # 3 я не міг заважати всім набравши текст, а натомість просто використовував загальнодоступні змінні.

Єдине, що мені не вистачає, це зробити це:

public string Name = "DefaultName";

Вам потрібно перенести за замовчуванням у ваші конструктори з властивостями. нудно :-(

Я думаю, що будь-яка конструкція, інтуїтивно зрозуміла І зменшує рядки коду, є великим плюсом.

Ці види функцій - це те, що робить мови, такі як Ruby, настільки потужними (що і динамічні функції, які також допомагають зменшити зайвий код).

У Рубі все це було так:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Єдина проблема, з якою у мене є, - це те, що вони не йдуть досить далеко. Той самий випуск компілятора, який додав автоматичні властивості, додав часткові методи. Чому вони не склали двох разом, це поза мною. Просте "часткове ввімкнення <PropertyName> Changed" зробило б ці речі справді корисними.

Це просто, він короткий, і якщо ви хочете створити реальну реалізацію всередині тіла властивості десь внизу лінії, це не порушить зовнішній інтерфейс вашого типу.

Так просто.

Тут слід зазначити одне, що, наскільки я розумію, це просто синтаксичний цукор на кінці C # 3.0, що означає, що IL, створений компілятором, є однаковим. Я згоден про те, щоб уникнути чорної магії, але все-таки менше рядків для однієї і тієї самої речі - це зазвичай добре.

На мою думку, ви завжди повинні використовувати автоматичні властивості замість публічних полів. Однак це є компроміс:

Почніть з внутрішнього поля, використовуючи конвенцію про іменування, яку б ви використовували для ресурсу. Коли ви вперше

• потрібен доступ до поля поза його складанням, або
• потрібно приєднати логіку до геттера / сеттера

Зробити це:

1. перейменуйте поле
2. зробити його приватним
3. додати суспільну власність

Ваш клієнтський код не потрібно буде змінювати.

Однак колись ваша система буде рости, і ви розкладете її на окремі збірки та декілька рішень. Коли це станеться, будь-які відкриті поля повернуться до переслідування, тому що, як зазначав Джефф, зміна публічного поля на публічну власність - це переломна зміна API .

Я використовую CodeRush, це швидше, ніж автоматичні властивості.

Зробити це:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Потрібно вісім натискань клавіш.

Ну а з фрагментами коду автоматеріал з однойменною назвою складатиме сім клавіш;)

@Domenic: Я цього не розумію .. хіба ти не можеш це зробити з автоматичними властивостями ?:

public string Title { get; }

або

public string Title { get; private set; }

Це те, про що ти маєш на увазі?

Моя найбільша боротьба з автоматичними властивостями полягає в тому, що вони створені, щоб заощадити час, але я часто виявляю, що мені доведеться пізніше розширити їх на повноцінні властивості.

Те, що VS2008 не вистачає, - це " Властивий автоматеріал" рефактор .

Той факт, що ми маємо інкапсульований рефактор поля, робить роботу, яку я швидше працюю, просто використовувати загальнодоступні поля.