Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
Наверно затем, чтобы хранить инфу, которую "можно сделать с помощью свойств".
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, snaphold, Вы писали:
S>>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>>Я рассматриваю только свойства имеющие оба акксесора.
AS>Наверно затем, чтобы хранить инфу, которую "можно сделать с помощью свойств".
а зачем лишние сущности, если я могу записывать, считывать и хранить всё это с помощью свойств?
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
М-да... Судя по всему, следующий вопрос (через пару лет) будет — зачем нужны циклы, если есть LinQ
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
Как реализуешь паттерн OnPropertyChanged без полей?
Здравствуйте, snaphold, Вы писали:
S>а зачем лишние сущности, если я могу записывать, считывать и хранить всё это с помощью свойств?
Поля как раз и применяются там, где свойства, а точнее его аксессоры — лишние сущности.
Здравствуйте, Lexxpin, Вы писали:
L>Как реализуешь паттерн OnPropertyChanged без полей?
Не, ну если захотеть, отдельными приватными свойствами
class Data : INotifyPropertyChanged
{
private int value
{
get;
set;
}
public int Value
{
get
{
return this.value;
}
set
{
if (this.value != value)
{
this.value = value;
this.OnPropertyChanged("Value");
}
}
}
...
}
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, snaphold, Вы писали:
S>>а зачем лишние сущности, если я могу записывать, считывать и хранить всё это с помощью свойств? MK>Поля как раз и применяются там, где свойства, а точнее его аксессоры — лишние сущности.
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
А вы в курсе что такое свойство с точки зрения CLR?
Здравствуйте, snaphold, Вы писали:
S>Пример в студию
Тут не пример нужен, а просто рассуждения. Что такое свойство? Это по сути два метода аксессора set и get. Поэтому любое обращение к свойству — это вызов метода (не будем принимать во внимание оптимизацию). Спрашивается, зачем мне вызывать метод для простого присваивания?
И потом, поля нужны для interop'а.
Советую также посмотреть этот
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
В основном по историческим причинам.
Ну, еще поле можно передать как ref/out параметр.
А в поле, типом которого является value-тип, легко можно поменять отдельное поле этого value-типа (но это можно было бы эмулировать и для свойств).
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, snaphold, Вы писали:
S>>Пример в студию MK>Тут не пример нужен, а просто рассуждения. Что такое свойство? Это по сути два метода аксессора set и get. Поэтому любое обращение к свойству — это вызов метода (не будем принимать во внимание оптимизацию). Спрашивается, зачем мне вызывать метод для простого присваивания?
А может, проще без рассуждений ? Выделено мной — PD
Auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field can only be accessed through the property's get and set accessors
А когда вы его declare не так как в этом example, то вам придется это поле создать вручную и в свойстве set в него что-то занести.
Здравствуйте, Aen Sidhe, Вы писали:
S>>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>>Я рассматриваю только свойства имеющие оба акксесора.
AS>Наверно затем, чтобы хранить инфу, которую "можно сделать с помощью свойств".
В языке вполне может не быть различий между полями, и тем, что в C# называется auto properties.
Например, поля в Scala — это совсем не то, что в C# называется полями. Например, они могут быть виртуальными, или принадлежать trait-у.
Просто C# — это довольно низкоуровневый язык (по крайней мере, он был таким в первых версиях), поэтому для него может иметь смысл говорить о физическом расположении данных в памяти.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А может, проще без рассуждений ? Выделено мной — PD
Обобщил просто.
PD>Auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors. When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field can only be accessed through the property's get and set accessors
PD>А когда вы его declare не так как в этом example, то вам придется это поле создать вручную и в свойстве set в него что-то занести.
И тем не менее, я привел пример, когда поля в классе нет, если абстрагироваться от того, что генерит компилятор. Это поведение (генерацию поля) в теории можно легко изменить, если из языка устранить само понятие поля. Ну т.е. сделать что-то вроде свойств хранилищ (бывшие поля) и свойств с аксессорами
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, MxKazan, Вы писали:
MK>>Здравствуйте, snaphold, Вы писали:
S>>>а зачем лишние сущности, если я могу записывать, считывать и хранить всё это с помощью свойств? MK>>Поля как раз и применяются там, где свойства, а точнее его аксессоры — лишние сущности.
S>Пример в студию
Любой объект с неизменным состоянием (immutable object).
One bad programmer can easily create two new jobs a year.
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
Хранить состояние объекта. Свойства отвечают за поведение, а не состояние.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>М-да... Судя по всему, следующий вопрос (через пару лет) будет — зачем нужны циклы, если есть LinQ
Этот вопрос был поставлен уже давно. Только звучал он немного по другому — "Зачем нужны циклы если есть рекурсивные функции, функции высшего порядка и макросы?".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, snaphold, Вы писали:
S>Скажите зачем нужны поля, если всё можно сделать с помощью свойств. S>Я рассматриваю только свойства имеющие оба акксесора.
Вопрос не так глуп как может показаться некоторым.
Только вопрос сформулирован не точно.
Физически поля несомненно нужны, так как только они могут хранить данные. Свойства — это не более чем синтаксический сахар для функций доступа.
Однако если рассматривать язык программирования, то свойства и поля действительно дублируют функциональность.
Я как-то уже думал на эту тему и пришел к выводу, что в языке можно было бы избавиться от лишней абстракции. Поля можно было бы переставлять как свойства с двумя публичными эксесорами. Это упростило бы язык и сделало бы более легким использование рефлексии (поля попросту можно было бы игнорировать во многих случаях).
Кроме того лишними элементами является ref- и out-параметры. Вместо них лучше было бы ввести в рантайм поддержку таких сущностей как кортежи (наборы разнотипных не именованных значений) и записи (наборы именованных разнотипных значений) которые можно было бы описывать прямо по месту (при декларации типа). Кортежи можно эмулировать и сейчас, а вот с записями все печально. Без поддержки рантайма качественно их не реализовать.
Вообще, в современных виртуальных машинах вроде дотнета и явы сделано много ошибок. В основном их причиной является то, что авторы этих рантаймов были знакомы только с ООП и КООП и не думали о поддержке ФП и МП.
На мой взгляд было бы интересно обсудить какие просчеты были сделаны в виртуальных машинах и языках. И то как должны выглядеть более совершенные ВМ и ЯП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
