Вот в теме "Что такое C#?" тов. Domestic Cat со свойственным ему рвением ругает properties.

Цитата(Domestic @ 20.6.2005, 19:34)

Писать на десяток символов меньше, и объединены гет/сет в один блок. Больше ничем. Зато появляется еще одна конструкция, усложняется документация. Если все на методах, то я, когда хочу что-то сделать, могу угадать название метода. А с пропертями мне нужно искать и в свойствах, и в методах. В результате я делаю мизерную экономию на наборе текста, но компенсирую это поиском в доках. Если учесть, что почти любая ИДЕ дает возможность сгенерить гет/сет методы, то вообще преимущество пропертей я не вижу...

Дабы не разводить оффтоп, решил создать отдельную тему, чтобы окончательно разрулить ситуацию

По-моему проперти для меня облегчают понимание кода, так как обычно их суть в том, чтобы по необходитмость проинициализировать/вычислить какое-либо значение и вернуть его пользователю. Мне психологически приятней писать:

Код

Color = Colors.Black;

чем

Код

setColor(Colors.Black);

Так как здесь очевидно, что свойству объекта присваивается какое-то значение.

Кроме того, отделение свойств от методов позволило создать такой компонент как PropertyGrid (хотя он, конечно, далёк от идеала ).

Сейчас мне некогда, но по-позже, с радостью попытаюсь обсудить объективные преимущества и недостатки этих подходов

Праально говоришь! Properties следюут принципу black-box - класс выставляет интерфейс взаимодействия с ним. Свойства:
1) Контролируют доступ к полям (раз есть поля, почему бы не быть оберткам вокруг них?)
2) Дают возможность реализовать некоторое поведение при обращении к ним, например lazy load при get, и вызов события вида "PropertyChanged" при set)

Ну вообще то если мы следуем принципам ОО то ситуация такая
1. Инкапсуляция: Отделение интерфейса (видимых методов) от имплементации (свойств объекта, его внутренней структуры) Проще говоря, поля объектов должны мыть максимум protected, publicом могут быть только константы.
2. Программа есть набор взаимодействующих объектов. Взаимодействие осуществляется путем пересылки сообщений - посредством методов. То есть, например myObject.setColor(Colors.Black) по сути есть отсылка сообщения объекту myObject. Как и что далее будет делать с этим сообщением объект - его дело, он для остальных объектов "черный ящик".

Микрософт попытался с введением свойств выделить методы, которые должны (по идее) менять какие-то свойства объекта. То есть, а.Color = Colors.Black меняет свойство объекта а, а например метод а.Resize() чего-то сделает с объектом.

Почему мне это не нравицца:
1. Не всегда однозначно можно отнести метод к той или иной группе. Например, GetHashCode(). Он реализован как метод, но ведь он также может быть рассмотрен и как свойство объекта.
2. Несмотря на то, что авторы FCL, видимо, следовали описанным выше принципам, никто не мешает им НЕ следовать. Возьмем проперти Environment.CurrentDirectory. Посмотрите, что оно делает - меняет текущую рабочую директорию. Почему это не метод? Тот же Resize - почему он не проперти Size?
3. Каков выигрыш от подобного разделения на свойства и методы? Что конкретно выиграно? Усложнены язык и документация, можно писать левый код, используя проперти там, где нужен метод, и наоборот. А выигрыша то нет, поиск по докам забирает (для меня по крайней мере) больше времени.
4. Какой конкретно ОО принцип реализует подобное нововведение? По-моему оно скорее противоречит ОО принципам, поскольку у пользователя создается впечатление, что свойства объекта меняются напрямую, тогда как суть не изменилась - внутри get{} set{} по-прежнему можно делать все что угодно. Вызов метода однозначно свидетельствует об отсылке сообщения, тогда как a.Number = 2
может означать как вызов метода set_Number() так и изменения паблик поля объекта.

Domestic Cat
Мне кажется, ту штука, котрорую ты не учитываешь - это то, что свойства дают возможность реализовать поля со сложным поведением. Т.е. никто не отменяет правила того, что программист должен думать, когда применять метод, а когда - свойство. ИМХО, поля вообще не должны быть public, потому что это как раз и будет нарушением инкапсуляции (спасибо, что напомнил, как называется то, о чем я писал постом выше).

Поэтому и создана отдельная сущность "свойство", которая выглядит как поле, но дает возможность определять поведение.

По 1, 2 согласен. Только что-то я не припомню метода Resize. Проперти Size -- есть
По 3 -- не знаю, меня это совсем не напрягает.
По 4 -- это уже фанатизм, батенька. Чистое ООП -- это же самая мерзкая бюрократия, которую только можно придумать... Не дай Бог, так и в жизни будет


ЗЫ: Я сейчас разбираюсь с X++ (Microsoft Axapta), так там вообще доступа к переменным класса извне нет! Только через методы. Причём нет разделения на гет и сет -- один метод с необязательным параметром

Это сообщение отредактировал(а) Дрон - 20.6.2005, 20:18

Цитата(arilou @ 20.6.2005, 11:17)

Поэтому и создана отдельная сущность "свойство", которая выглядит как поле, но дает возможность определять поведение

Дык я и хочу сказать, что в таком случае это выглядит как изменение поля, тогда как на самом деле это отсылка сообщения объекту, т.е. то же самое, что и метод.
Добавлено @ 20:30

Цитата

Только что-то я не припомню метода Resize. Проперти Size -- есть

Это для примера было, хотя вообще-то и такое есть:
http://www.bluebit.gr/NET/Library/index.as...tor-Resize.html

Вот другой пример: Control.Focus() - метод. Почему он не свойство (Focus = true) ?
С др. стороны: Control.Size - свойство, почему оно не метод?
В чем принципиальное отличие? И Focus, и Size меняют некие характеристики объекта - его размер и наличие фокуса.

Меня лично смущает только одно - я не вижу точно, что я делаю. Вызываю ли я метод или меняю переменную.

Если мы говорим о самой жесткой инкапсуляции, то тогда понятно по умолчанию - это просто еще одна форма записи. Но происходит вызов функции или посылка сообщения методу.

Но вся штука в том, что неоднократно встречал открытые поля, которые менять хорошо бы через методы, но тем не менее их видно. Бывает, что поле вообщем-то и хорошо, что открыто.
И вот тут возникает неоднозначность - все-таки что я меняю ? Проперть или просто поле. Каждый раз я должен быть внимателен и осторожен. И если проперти делались для того, чтобы в какой-то степени облегчить мою жизнь, то я как раз вижу обратное.
Без пропертей все ясно и очевидно - это поле или метод. Никаких неоднозначностей.

Интересная штука получается...

Цитата(AntonSaburov @ 20.6.2005, 20:32)

я не вижу точно, что я делаю

Ну ты же сам принимаешь решение о том, чтобы сделать свойство или метод, так? Т.е. ты чувствуешь, когда нужно одно, а когда другое?

Вот например у меня. Есть реестр инстансов определенных классов. Мне нужно достать оттуда какой-нить инстанс по ключу. Я определяю индексатор (обычное свойство с параметром), и внутри него достаю нужный мне объект из hashtable. Почему свойство? Потому что
1) мне кажется, что данная операция не является посылкой сообщения классу
2) индексатор в данном случае - понятийное свойство реестра, его характеристика вида "содержимое реестра для данного ключа" (постарайтесь понять мою мысль прежде чем спорить о том, характеристика это или нет)

Другой пример. У меня есть бизнес-объекты. Они ссылаются на другие бизнес-объекты. Например, есть сущность User, которая содержит ссылку на сущность Role. Role в данном случае - характеристика User, а это значит, что она реализуется в виде свойства Role, а не метода getRole(). Соответственно, если я хочу сменить роль пользователю, то я меняю его характеристику, а не посылаю ему сообщение "смени роль", это я решаю выполнить эту оперецию, а не сама сущность "пользователь".

Вот если бы я хотел сделать, чтобы пользователь мог сменить роль какого-то другого пользователя, то я бы сделал метод setUserRole(user, newRole), а в нем проверял бы, может исполнитель сменить роль другого пользователя, или нет. Или более того, я бы вынес это в сервисный класс, и сделал бы метод там setUserRole(performedBy, targetUser, newRole)

Вот мое видение свойств. Буду ждать комментов.

Цитата(arilou @ 20.6.2005, 12:03)

Role в данном случае - характеристика User, а это значит, что она реализуется в виде свойства Role, а не метода getRole().

Не понимаю. Свойство - это то же что и метод, реализация свойства в IL - это методы get_XXX, set_XXX.
И в ООП ничего, кроме отсылки сообщений нет.
Объясни мне разницу между Role и getRole?

Цитата(arilou @ 20.6.2005, 12:03)

Соответственно, если я хочу сменить роль пользователю, то я меняю его характеристику, а не посылаю ему сообщение "смени роль", это я решаю выполнить эту оперецию, а не сама сущность "пользователь".

Ну так нигде в ООП нет разделениай на то, что, кто и как должен делать. Ты отсылаешь сообщение - а далее ОБъЕКТ решает какие действия предпринять. И в случае с методами, и в случае со свойствами.

Цитата(arilou @ 20.6.2005, 12:03)

Вот если бы я хотел сделать, чтобы пользователь мог сменить роль какого-то другого пользователя, то я бы сделал метод setUserRole(user, newRole),

Давай так: каковы четкие правила, где применят; свойство, а где - метод. И объясни мне тода мои примеры насчет реализаций в FCL
И какие выгоды дает это разделение.

Цитата(arilou @ 20.6.2005, 12:03)

Ну ты же сам принимаешь решение о том, чтобы сделать свойство или метод, так? Т.е. ты чувствуешь, когда нужно одно, а когда другое?

Кстати, ведь не всегда пользуешь код, который сам писал. Да и невозможно в любом случае упомнить все. Просто обозначения для изменения паблик полей и свойств одинаковые, а суть-то разная.

Цитата(AntonSaburov @ 20.6.2005, 21:32)

Без пропертей все ясно и очевидно - это поле или метод

А какая разница?
Раз мы принимаем инкапсуляцию, значит нам должно быть всё равно как класс устроен внутри. Он предоставляет нам интерфейс и мы его используем, не задумываясь, что при этом происходит.

Цитата(Domestic @ 20.6.2005, 22:15)

Объясни мне разницу между Role и getRole?

Читать приятней
role = SomeUser.Role; читается как: присвоить переменной role значение Role объекта SomeUser
С методом оно читалось бы: присовить переменной роль, значение возвращаемое методом getRole, что ИМХО уже не так естественно.

Domestic Cat, одна из выгод от применения пропертей состоит в том, что "свойство" воспринимается как "поле", и наоборот, т.е. я в любой момент могу заменить любое public-поле или константу класса на вычисляемое св-во, не переписывая ни строчки кода.

Ещё пример. Свойство может представлять из себя ресурс "по требованию", т.е. инициализировать и возвращать значение при первом запросе.

Другой пример. Паттерн "singleton" с использованием свойств воспринимается в коде намного естественнее, чем с использованием методов: Class.Instance.DoSomething() против Class.getInstance().DoSomething().

Наконец, пиная майкрософт, нужно обратить внимание на open-source разработчиков: почему-то все поголовно используют проперти на шарпе, см. хотя бы CodeProject.

Цитата(mr @ 20.6.2005, 14:37)

Class.Instance.DoSomething() против Class.getInstance().DoSomething().

Обясняю позицию:
myObject.methodA().methodB() расшифровывается так:

Взять объект myObject и отослать ему сообщение methodA(), возвращаемому значению отослать сообщение methodB()

myObject.A.methodB()
Свойству объекта myObject отослать сообщение methodB().

Теперь вот такой вопрос: первая реализация через методы абсолютно абстрагируется от природы возвращаемого значения после вызова methodA. Вторая реализация фактически читается как "взять нечто, принадлежащее объекту myObject и передать ему сообщение".
Заметьте, вторая ситуация ограничивает девелопера - это будет "правильно" только если A является действительно полем объекта myObject. Но ведь если например мы меняем реализацию, и теперь А хранится не как поле, а создается в методе set{} - все, проперти перестало быть свойством и должно по логике стать методом.
ТЕперь, какие преимущества?
1. Удобство?
Разница между Class.Instance.DoSomething() и Class.getInstance().DoSomething() - две скобки.
2. Что еще? Ну хорошо, свойство говорит мне о том, что А - это некое поле объекта. Ну и что? Собственно, мне не должно быть никакого дела, поле это, или еще что. Логика ведь не зависит от того, присваиваю я значение пропертям или вызываю методы.

Цитата(mr @ 20.6.2005, 14:37)

Наконец, пиная майкрософт, нужно обратить внимание на open-source разработчиков: почему-то все поголовно используют проперти на шарпе, см. хотя бы CodeProject.

Дык, мало ли что используют. Вижуал Васик 6 тоже довольно популярен Это шутка, я не сравниваю Васик со свойствами, просто если добавить в язык что-то, это что-то обязательно будут пользовать.

Цитата(Domestic @ 21.6.2005, 01:19)

myObject.methodA().methodB() расшифровывается так: Взять объект myObject и отослать ему сообщение methodA(), возвращаемому значению отослать сообщение methodB()

Ну почему обязательно "сообщения"?

Цитата(Domestic @ 21.6.2005, 01:19)

myObject.A.methodB() Свойству объекта myObject отослать сообщение methodB().

Не "свойству объекта", а "возвращаемому свойством значению" отослать сообщение. Что же здесь "не так" ?

Цитата(Domestic @ 21.6.2005, 01:19)

... просто если добавить в язык что-то, это что-то обязательно будут пользовать.

Неправда, те же индексаторы на том же шарпе используются ну очень редко, т.к. весч довольно специфичная, чего не скажешь о properties.

Кстати, почему бы нашим уважаемым оппонентам не вспомнить о линейке продуктов Borland (CBuilder, Delphi), о языках, средах разработки, визуальных и прочих компонентах, завязанных на свойства?

Цитата(mr @ 21.6.2005, 00:12)

Ну почему обязательно "сообщения"?

Потому, что это принятая в ООП терминология.

Цитата(mr @ 21.6.2005, 00:12)

Не "свойству объекта", а "возвращаемому свойством значению" отослать сообщение. Что же здесь "не так" ?

"возвращаемому свойством значению" - звучит очень похоже на "возвращаемому методом значению" То есть по-твоему свойство - это скорее метод ?

Цитата(mr @ 21.6.2005, 00:12)

Неправда, те же индексаторы на том же шарпе используются ну очень редко, т.к. весч довольно специфичная, чего не скажешь о properties.

Ну почему, в FCL много чего на них, особенно АДО, ДатаГрид, и пр.

Цитата(mr @ 21.6.2005, 00:12)

Кстати, почему бы нашим уважаемым оппонентам не вспомнить о линейке продуктов Borland (CBuilder, Delphi), о языках, средах разработки, визуальных и прочих компонентах, завязанных на свойства?

Мы же не о них говорим, правильно? Да и что это доказывает?

Цитата(Domestic @ 20.6.2005, 21:15)

Не понимаю. Свойство - это то же что и метод, реализация свойства в IL - это методы get_XXX, set_XXX. И в ООП ничего, кроме отсылки сообщений нет.

Подожди, в данном случае не важно, как это реализовано в IL. Ты понимаешь любую операцию над классом как отсылку сообщения. ОК. Обращение к свойству - та же самая посылка сообщения. Но самое главное тут, что в свойстве объединяются методы и поля. Корпускулярно-волновую теорию света помнишь? То же самое и тут. Свойство несет двойной смысл - как поля, так и метода. И я не вижу тут никакого противоречия. Конечно, никто не запрещает тебе не испольщовать свойств вообще. Просто, если ты пишешь .NET код, то тебе нужно поддерживать культуру, которая сложилась в команде разработчиков. Если же вся команда на Java писала, а теперь на C#, то тогда, конечно, я могу всё понять

Цитата(Domestic @ 20.6.2005, 20:05)

1. Не всегда однозначно можно отнести метод к той или иной группе. Например, GetHashCode(). Он реализован как метод, но ведь он также может быть рассмотрен и как свойство объекта.

1. Свойство следует применять в тех случаях, когда последовательное обращение к нему без каких-либо других изменений в членах класса всегда будет возвращать один и тот же результат. GetHashCode() - это метод, потому что его реализация может быть построена таким образом, что возвращаемые знаяения будут разными в зависимости от неопределенных факторов.

Цитата(Domestic @ 20.6.2005, 20:05)

2. Несмотря на то, что авторы FCL, видимо, следовали описанным выше принципам, никто не мешает им НЕ следовать. Возьмем проперти Environment.CurrentDirectory. Посмотрите, что оно делает - меняет текущую рабочую директорию. Почему это не метод? Тот же Resize - почему он не проперти Size?

2. Разве текущая директория - это не характеристика? Сколько не пляши, возвращаемое значение будет одинаковым, пока ее не изменишь

Цитата(Domestic @ 20.6.2005, 20:05)

3. Каков выигрыш от подобного разделения на свойства и методы? Что конкретно выиграно? Усложнены язык и документация, можно писать левый код, используя проперти там, где нужен метод, и наоборот. А выигрыша то нет, поиск по докам забирает (для меня по крайней мере) больше времени.

3. Да, без четкого понимания можно писать дебильный код, когла свойства используются не по назначению. Тоже самое и на C++ - можно не использовать указатели, там где это нужно, а испольщовать, например, индексы. Тоже получится дебильный код. Наверняка и на Java можно, не имея достаточных знаний, писать абы что.

Выиграно то, что видно, какие у объекта характеристики, и какие операции он поддерживает. Твой пример о Resize и Size. Могу предположить следующее:
1) Класс писался не одним человеком. В итоге получили два способа
2) В MS любят уважить сразу бОльшее кол-во программеров. В итоге есть несколько путей сделать ту или иную штуку - посмотри только в WinAPI.

Еще, твоя позиция о сообщениях почему-то напоминает мне о войне между процедурным программированием и ООП, когда приверженцы первого говорили "зачем мне классы, если я могу обойтись без них". ИМХО, не надо так фанатично отстаивать "чистое" ООП. Если бы все стояло на месте, писали бы программы до сих пор на перфокартах. А так, единожды поппробовав использовать свойства, ты бы потом не понял, как вообще можно без них обходиться.

Кстати, в .NET 2.0 появилась возможность задавать getter'ы и setter'ы с разной степенью доступности (private, protected, internal). Это то, чего 100% не хватало в 1.1, и за что многие ругали MS, и говорили - "если свойства - это те же методы, то почему нельзя задать им разную доступность?.

Цитата(arilou @ 21.6.2005, 01:13)

1. Свойство следует применять в тех случаях, когда последовательное обращение к нему без каких-либо других изменений в членах класса всегда будет возвращать один и тот же результат. GetHashCode() - это метод, потому что его реализация может быть построена таким образом, что возвращаемые знаяения будут разными в зависимости от неопределенных факторов.

Хм.. Это официальное определение? Против него можно найти сколько угодно примеров в .НЕТ : например проперти Size. Если юзер изменил размеры формы - размер изменился, хотя явно я его не менял, вообще ничего не делал.

Цитата(arilou @ 21.6.2005, 01:13)

2. Разве текущая директория - это не характеристика? Сколько не пляши, возвращаемое значение будет одинаковым, пока ее не изменишь smile

Однако, это важная характеристика, не так ли? Почему например, не реализовать свойство FileInfo.Exists с set {} : file.Exists = false? Вот какой простой пример удаления файла
Где граница между свойством и методом?

Цитата(Domestic @ 21.6.2005, 10:12)

"возвращаемому свойством значению" - звучит очень похоже на "возвращаемому методом значению"  То есть по-твоему свойство - это скорее метод ?

Да.
Отличие свойства от поля - то, что у свойства есть поведение. Поэтому св-во это суть метод (один или два метода), представляющий обёртку над полем. У св-ва, как и у метода, есть возвращаемое значение (у get) и аргумент (у set).

Цитата(Domestic @ 21.6.2005, 10:12)

Мы же не о них говорим, правильно? Да и что это доказывает?

Это пример предметной области, в которой широко используются свойства, полностью аналогичные св-вам C#.


Добавлено @ 10:28

Цитата(Domestic @ 21.6.2005, 10:22)

Где граница между свойством и методом?

Свойство - это скорее "умное поле", чем "действие". По поводу того, как и когда применять свойства, каждый решает сам. Не думаю, что кто-то, будучи в здравом уме, решит написать "File.Exists = false" для удаления файла. Это то же самое что сказать "файл не существует ! трах-тибидох ! исчезни !" вместо "давай удалим-ка этот файл".

Цитата(Domestic @ 21.6.2005, 10:22)

Хм.. Это официальное определение

Да. Я читал это в MSDN Technical Articles.

Цитата(Domestic @ 21.6.2005, 10:22)

например проперти Size. Если юзер изменил размеры формы - размер изменился, хотя явно я его не менял, вообще ничего не делал.

С одной стороны ты прав. Но с другой стороны, возможно, такое свойство нужно было сделать readonly, тогда бы и не возникало противоречия.

Цитата(Domestic @ 21.6.2005, 10:22)

file.Exists = false?

Не, ну не надо такого цинизма! Покажи мне человека в здравом уме, который такое напишет.
Добавлено @ 10:40

Цитата(Domestic @ 21.6.2005, 10:22)

Где граница между свойством и методом?

Истина посередине. Фотон - это и частица, и волна. Свойство - это и поле, и метод.
Добавлено @ 10:44

Цитата(Domestic @ 21.6.2005, 10:22)

file.Exists = false

Это мне напонимает такое (за синтаксис я не ручаюсь, но меня поймут)

Код

#define MACRO(x) printf("%d^2=%d", x, x*x) // ..... MACRO(++d); printf("%d", d);

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

Цитата(mr @ 21.6.2005, 01:24)

Свойство - это скорее "умное поле", чем "действие". По поводу того, как и когда применять свойства, каждый решает сам. Не думаю, что кто-то, будучи в здравом уме, решит написать "File.Exists = false" для удаления файла. Это то же самое что сказать "файл не существует ! трах-тибидох ! исчезни !" вместо "давай удалим-ка этот файл".

Да, но следуя определению из

Цитата(arilou @ 21.6.2005, 01:39)

MSDN Technical Articles.

ничто не препятствует созданию такого свойства

Цитата(Domestic @ 21.6.2005, 10:45)

ничто не препятствует созданию такого свойства

Котъ, у меня такое ощущение, что ты не хочешь ничего понять.

Цитата(arilou @ 21.6.2005, 01:48)

Котъ, у меня такое ощущение, что ты не хочешь ничего понять.

У меня такое же, только наоборот. Но я сейчас почти сплю. Потому отвечу часов через восемь.

Цитата(arilou @ 20.6.2005, 21:03)

Ну ты же сам принимаешь решение о том, чтобы сделать свойство или метод, так? Т.е. ты чувствуешь, когда нужно одно, а когда другое?

Это когда я пишу сам. А когда я пользуюсь какой-то библиотекой ?

Понятно, что если соблюдать правила и писать высоко профессионально, то проперти будут работать и облегчать жизнь. Но IMHO не настолько они ее облегчают, насколько усложняют синтаксис и дают еще одну лазейку запутаться. И если уж писать высокопрофессионально, то красиво можно писать на любом языке.

Т.е. IMHO - ввод пропертей не дает большого выигрыша для профессионалов, а для начинающих это лишний повод поиграть. Что сами понимаете ничего хорошего не дает.

Давайте определимся, говорим мы о применении свойств программистами разного уровня, или об использовании свойств как конструкции языка. Это же разные вещи.

Насчёт

Цитата(AntonSaburov @ 21.6.2005, 11:18)

Это когда я пишу сам. А когда я пользуюсь какой-то библиотекой ?

Волков бояться - в лес не ходить. Нормальные библиотеки (какие использует более 1-го девелопера) пишуть нормальные программеры, отличающие проперти от метода.

Цитата(AntonSaburov @ 21.6.2005, 11:18)

Но IMHO не настолько они ее облегчают, насколько усложняют синтаксис и дают еще одну лазейку запутаться. И если уж писать высокопрофессионально, то красиво можно писать на любом языке.

Согласен со второй частью. Первая же - это имхо, т.к. никакого усложнения лично я не вижу.

Народ, почитайте Буча. Я хотел сначала цитату привести, потом понял, что надо всю книгу сюда копировать Он очень много про свойства говорит.

Попытаюсь еще раз

1. Де юре и де факто свойства - это методы гет/сет, для которых изменен синтаксис. Все! Они и реализованы по сути как методы.
2. Если так, то в чем их преимущество? Вариант А: меньше набирать. Личное мое мнение в том, что основная причина, по которой их называют "удобными" и т п состоит в том, что при ручном наборе присвоить значение свойству быстрее на несколько символов. Создать свойство быстрее на 10-15 символов.
3. Но реально это чепуха - длай быстрого "наборщика" это секунда. При использовании средств RAD это вообще не играет никакогй роли.
4. Вариант Б: свойство свидетельствует о чем то. О чем? Что изменение свойства не приведет к каким-то кардинальным изменениям? Что свойство - это "свойство объекта х"?
5. -------------------------------------------
6. Больше ничего за свойствами нет.
7. В связи с п 4. Возникают вопросы: 1. Каков четкий критерий использования свойств? 2. Методы позволяют сделать то же самое. setSpeed не менее выразителен, чем Speed = .... Если так, то зачем нужны свойства?
8. Получается, чт п.4 отпадает. Но против п.2 вот что:
9. Введена еще идна сущность в язык.
10. => Усложнена документация
11. => Усложнен язык
12. => Синтаксис использования свойства совпадает с синтаксисом доступа к паблик полю, что НЕ приветствуется в ООП (паблик поля). Например, новичок может сделать все поля какого-либо класса публичными ("для простоты"), а я буду думать что все ок и это свойства.
13. => Усложнен процесс дизайна, нужно выбирать между методом и свойством, тогда как никаких действующих на 100% правил я не нашел. Более того, редко в какой книге затронут этот вопрос.
14. => Плохой дизайн + различное понимание смысла свойств могут приводить к еще большей путанице. Пример с Exists очевиден, но что если речь идет о написании сотен классов? Хочешь не хочешь, а "странные" свойства будут созданы. Тогда как с методами такой проблемы не возникает.

Цитата(Domestic @ 21.6.2005, 19:12)

10. => Усложнена документация 12. => Синтаксис использования свойства совпадает с синтаксисом доступа к паблик полю, что НЕ приветствуется в ООП (паблик поля).

10 - мне удобнее читать документацию, когда методы и свойства разделены.
12 - но это же не паблик поле

Добавлено @ 18:21

Цитата(Domestic @ 21.6.2005, 19:12)

13. => Усложнен процесс дизайна, нужно выбирать между методом и свойством, тогда как никаких действующих на 100% правил я не нашел. Более того, редко в какой книге затронут этот вопрос.

С одной стороны ты прав. Но с другой точно так же можно сказать и про методы: в чём разница между использованием методов getSize() и Size(). По какому принципу к названию метода приписывается get? И вдруг какой-нибудь индус вообще не знает такой записи, и пишет не get, а pleaseGiveMeValueOf. Попробуй пойми, что он хотел сказать. Проперти же стандартизированы

Это сообщение отредактировал(а) Дрон - 21.6.2005, 18:17

Цитата(Domestic @ 21.6.2005, 18:12)

Попытаюсь еще раз

Лучше бы ты прочитал все те посты, которые были написаны, и над ними подумал, чем еще раз писать одно и то же. Тут было много написано, и ни на один аргумент ты ничего не ответил. Я считаю, что это пренебрежение к оппонентам.

Цитата

И вдруг какой-нибудь индус вообще не знает такой записи, и пишет не get, а pleaseGiveMeValueOf. Попробуй пойми, что он хотел сказать. Проперти же стандартизированы

Как говорят англикосы, I second that, что значит примерно "я подписываюсь под этим тоже"

Domestic Cat, да на здоровье. Методы, так методы. Помнится, ты аналогичным образом критиковал делегаты, приводя контрпример в виде методов-листенеров. Такое впечатление, что кроме методов больше в ООП ничего не юзается (шаг влево, шаг вправо - расстрел).

P.S. а книгу мистера G. Booch всё же почитать бы стоило.

Цитата

По какому принципу к названию метода приписывается get? И вдруг какой-нибудь индус вообще не знает такой записи, и пишет не get, а pleaseGiveMeValueOf. Попробуй пойми, что он хотел сказать. Проперти же стандартизированы smile

Согласен, метод можно назвать как угодно, но я ведь говорю о том, что преимущества в этом плане у свойств нет. свойство тоже можно назветь как угодно или сделать методом.

Цитата

12 - но это же не паблик поле smile

Из записи a.B = 33 это определить невозможно.

Цитата(arilou @ 21.6.2005, 09:27)

Лучше бы ты прочитал все те посты, которые были написаны, и над ними подумал, чем еще раз писать одно и то же. Тут было много написано, и ни на один аргумент ты ничего не ответил. Я считаю, что это пренебрежение к оппонентам.

Ну я перечитал тему еще раз. Кроме Дрона, никто не попытался четко и ясно ответить на подняты мнои вопросы.

Цитата(mr @ 21.6.2005, 09:29)

Domestic Cat, да на здоровье. Методы, так методы. Помнится, ты аналогичным образом критиковал делегаты, приводя контрпример в виде методов-листенеров. Такое впечатление, что кроме методов больше в ООП ничего не юзается (шаг влево, шаг вправо - расстрел).

Если ты помнишь, вопрос про делегаты был поднят именно на этом форуме, и не мной. Да, я их критиковал, но могу дать ссылки на мои посты, где я утверждаю, что данное решение ничуть не хуже листенеров.

Цитата(mr @ 21.6.2005, 09:29)

P.S. а книгу мистера G. Booch всё же почитать бы стоило.

Товарищи, здесь не соревнование "кто кого перецитирует". Мы собираемся на форуме не только для того, чтобы ответить на вопросы "а почему я не могу запустить программу". Гораздо интереснее приходить сюда и общаться на несколько более глубокие темы. Если хотите - объясните ваши аргументы, а Гради Буча я и сам могу почитать. Не хотите - можем закрыть тему.

Цитата(Domestic @ 21.6.2005, 19:46)

Из записи a.B = 33 это определить невозможно.

ПОВТОРЯЮ: а какая нам разница, что это такое??? Раз класс предоставил нам доступ к этому, значит мы можем этим пользоваться.
Если же мы правим сам класс, то что мешает щёлкнуть правой кнопкой и выбрать Go to definition

Это сообщение отредактировал(а) Дрон - 21.6.2005, 18:54

Цитата

ПОВТОРЯЮ: а какая нам разница, что это такое??? Раз класс предоставил нам доступ к этому, значит мы можем этим пользоваться.

С точки зрения кодера: да, ты прав, кодеру все равно. А я говорю о ДИЗАЙНЕ ЯЗЫКА. Посмотри на это с такой точки зрения. Если я смотрю код Васи Пупкина и вижу а.с то я не знаю, что это. Если это ошибка, и Вася Пупкин создал паблик поле, то это плохо.

Цитата(Domestic @ 21.6.2005, 18:46)

Кроме Дрона, никто не попытался четко и ясно ответить на подняты мнои вопросы.

1) http://forum.vingrad.ru/index.php?showtopi...ndpost&p=447783

Цитата(arilou @ 21.6.2005, 10:39)

Где граница между свойством и методом? Истина посередине. Фотон - это и частица, и волна. Свойство - это и поле, и метод.

Цитата(mr @ 21.6.2005, 12:29)

Нормальные библиотеки (какие использует более 1-го девелопера) пишуть нормальные программеры, отличающие проперти от метода.

и свойства.

Цитата(arilou @ 21.6.2005, 10:39)

Цитата (Domestic Cat @ 21.6.2005, 10:22) file.Exists = false?

Это не пример. Как и это:

Код

char *p; p = "dddd";

Не знаешь указателей, будешь плодить маразм. Не знаешь, когда и как применять свойства?

Цитата(arilou @ 21.6.2005, 10:13)

Свойство следует применять в тех случаях, когда последовательное обращение к нему без каких-либо других изменений в членах класса всегда будет возвращать один и тот же результат

Это официальная информация.

Цитата(Domestic @ 21.6.2005, 10:45)

ничто не препятствует созданию такого свойства

Использовать неинициализированные указатели тоже ничто не препятствует. Это не аргумент.

Цитата(Domestic @ 21.6.2005, 18:12)

Все! Они и реализованы по сути как методы.

Да, они реализованы как методы. Но выглядят как поля. Но ими не являются

Цитата(Domestic @ 21.6.2005, 18:12)

Если так, то в чем их преимущество

Вариант Б: есть четкая разница между свойствами объекта, и его операциями - облегчение понимания.

Domestic Cat
ОК. Принято
Позволю себе немного нехороший ход...

А если тов. Пупкин создал такое:

Код

private int field; public int getField() {      return field; } public void setField(int val) {      field = val; }

То это хорошо?

ЗЫ: Кстати Visual Studio в выпадающих списках различает поля и свойства.

Цитата(arilou @ 21.6.2005, 10:02)

Это официальная информация.

В прочтенных мной книгах я не помню, чтобы это упоминалось Разве что Троелсен. Но ведь продолжение такое: данное правило не сработает во многих случаях. Я приводил пример свойства Size. Я приводил пример свойства Exists.

Цитата

То это хорошо? smile

Цитата(arilou @ 21.6.2005, 10:02)

Вариант Б: есть четкая разница между свойствами объекта, и его операциями - облегчение понимания.

То же самое можно сказать и о get/set методах. Они тоже проводят границу между своиствами и действиями, но отличие в том, что нет жесткого разграничения синтаксиса.

Цитата(arilou @ 21.6.2005, 10:02)

Где граница между свойством и методом? Истина посередине. Фотон - это и частица, и волна. Свойство - это и поле, и метод. Цитата (mr.DUDA @ 21.6.2005, 12:29) Нормальные библиотеки (какие использует более 1-го девелопера) пишуть нормальные программеры, отличающие проперти от метода. и свойства.

Цитата(arilou @ 21.6.2005, 10:02)

Да, они реализованы как методы. Но выглядят как поля. Но ими не являются

Из твоих слов определить что должно быть своством, а что методом нельзя, разве ты не видишь?

Цитата

А если тов. Пупкин создал такое: private int field; public int getField() {     return field; } public void setField(int val) {     field = val; } То это хорошо? smile

Да, это хорошо, гораздо лучше чем puvlic int field. Именно это и есть ООП. Не понимаю почему это плохой код.

Цитата(Domestic @ 21.6.2005, 19:17)

Из твоих слов определить что должно быть своством, а что методом нельзя, разве ты не видишь?

Почему ты считаешь, что использование того или иного свойства языка должно быть четко формализовано? У нас была написана программа на C++, которая в целях усложнения взлома результаты функций возвращала через exceptions. Но никто же не предпологал, когда их проектировали, что они будут так использоваться!

Цитата(Domestic @ 21.6.2005, 19:17)

Но ведь продолжение такое: данное правило не сработает во многих случаях. Я приводил пример свойства Size. Я приводил пример свойства Exists.

Я приводил пример с указателями. Но ведь никто не говорит, что указатели - это плохо.

Цитата(Domestic @ 21.6.2005, 19:17)

Да, это хорошо, гораздо лучше чем puvlic int field.

Я бы сказал, что это хорошо, но лучше было бы свойством - ведь все что делается - это меняется значение private поля.

Я считаю, что все зависит от культуры программирования. У меня в команде, слава Богу, никто не пишет идиотских свойств.

Цитата(Domestic @ 21.6.2005, 20:17)

Да, это хорошо, гораздо лучше чем puvlic int field. Именно это и есть ООП. Не понимаю почему это плохой код.

А я как-то и не вижу разницы с public int field; кроме как в ухудшении быстродействия

Если серьёзно, то мне кажется, что Domestic Cat слишком увлекается теорией ООП как таковой.

Конечно, я в обычных условия никогда не сделаю паблик переменную... Но когда я вижу такие методы из одного присваивания или ретурна, то меня просто плющит

Это сообщение отредактировал(а) Дрон - 21.6.2005, 19:29

Цитата

Раз класс предоставил нам доступ к этому, значит мы можем этим пользоваться.

Предоставил программист. И даже в Майкрософт (гдена самом деле пишут очень приличный код и там отнюдь не дураки работают) делает иногда странные вещи.
Что говорить о системах, которые сделаны для заказчика, нет толком документации, нет даже описания или оно сделано для системы двухлетней давности.

И вот разбирая 218-ую функцию мы видим надпись

Код

a.val = 33;

Ну и что вы будете делать ? Правильно - пойдете и будете смотреть - это свойство или паблик поле. Неоднозначность есть ? Очевидно, что есть. А в случае

Код

a.setVal(33);

Вы будете уверены в том, что это реально вызывается функция.

Поначалу мне проперти в delphi казались очень удобными. Было даже приятно сделать

Код

DataSet.Active = True; ... DataSet.Active = False;

Потом оказалось, что гораздо понятнее сделать DataSet.Open. А DataSet.Active использовать только для проверки. Но вызов мало чем отличается от DataSet.IsActive() (гипотетический вызов).
Может для кого-то этот пример является удобством, но для меня - однозначно нет.

Лишнее дублирование, проперти ReadOnly - это без особых хлопот заменяется вызовом методов. Мало того - в том же Delphi описание проперти сделано вообщем-то корявенько. В .NET уже приличнее.

Язык должен быть не только удобным, но и должен быть все-таки с достаточной мере ЛАКОНИЧНЫМ. А введение пропертей (во всяком случае в C#) выглядит еще одной мулечкой, которую вообщем-то можно было бы убрать без особых хлопот.
Добавлено @ 19:38

Цитата

Но когда я вижу такие методы из одного присваивания или ретурна, то меня просто плющит

Может приведем код для проперти ?

Код

public int MyNumber  { // Retrieves the number data member. get     {        return number;     } // Assigns to the number data member. set     {        number = value;    } }

Здесь что-то по-другому ?

Цитата(arilou @ 21.6.2005, 10:23)

Почему ты считаешь, что использование того или иного свойства языка должно быть четко формализовано? У нас была написана программа на C++, которая в целях усложнения взлома результаты функций возвращала через exceptions. Но никто же не предпологал, когда их проектировали, что они будут так использоваться!

Managed язык, претендующий на простоту обязан быть четко формализован. Свобода С++ как раз и делает его сложным языком, не говоря уже о том, что при вольном написании кода можно создать кучу багов и сделать его нечитаемым. Но в случае с С/С++ этооправдано, т.к. это также и "низкоуровневый" язык.

Цитата(arilou @ 21.6.2005, 10:23)

Я приводил пример с указателями. Но ведь никто не говорит, что указатели - это плохо.

Вообще говоря, их потому и убрали из Java и почти убрали из С# - потому что это не нужно для решаемых этими языками задач, а следовательно плохо.

Цитата

А я как-то и не вижу разницы с public int field; кроме как в ухудшении быстродействия.

Ухудшение это мизерное. Зато это ОО код. Если завтра придется менять реализацию, убирать поле field, и вместо этого обращаться к БД, то тебе придется перелопатить сотню классов, чтобы обнаружить, кто и где вздумал написать myClass.field и заменить все эти вызовы на вызов метода, поскольку field перестало быть полем а стало чето-то делать.

Цитата(AntonSaburov @ 21.6.2005, 20:34)

А введение пропертей (во всяком случае в C#) выглядит еще одной мулечкой, которую вообщем-то можно было бы убрать без особых хлопот

А как бы тогда работал компонент PropertyGrid? Активно используемый в самой студии.

Цитата(AntonSaburov @ 21.6.2005, 19:34)

Язык должен быть не только удобным, но и должен быть все-таки с достаточной мере ЛАКОНИЧНЫМ. А введение пропертей (во всяком случае в C#) выглядит еще одной мулечкой, которую вообщем-то можно было бы убрать без особых хлопот.

Да, давайте уберем свойства и делегаты с событиями, и получим очередной клон Java, который реально ничего лучше не делает, да? Тогда пуристы будут спать спокойно. Я рад, что никто пока не предложил делать public поля. Это хорошо, что спор идет вокруг свойств и методов.

С таким же успехом можно на ассемблере писать. Хотя нет. Там же куча взаиозаменяемых команд. Тогда на перфокартах.

Извините за цинизм, но вы сами к этому подвели. Давайте вспомним такой язык как Лого. Или еще! Зачем нам рекурсия, ведь в Прологе без нее отлично обходятся?! Вырежем рекурсию.

Цитата(AntonSaburov @ 21.6.2005, 19:34)

И вот разбирая 218-ую функцию мы видим надпись

Откроем Intellisense и увидим, что это свойство. Нету VS.NET? В SharpDevelop Intellisense тоже есть. Другие среды для .NET я не видел. А если в блокноте? Ну не знаю... Попробуем сгенерить ndoc'ом документацию по коду, и будем там смотреть. Главное - голова и руки чтоб на месте были.

Цитата(Domestic @ 21.6.2005, 20:41)

сли завтра придется менять реализацию, убирать поле field, и вместо этого обращаться к БД, то тебе придется перелопатить сотню классов, чтобы обнаружить, кто и где вздумал написать myClass.field и заменить все эти вызовы на вызов метода, поскольку field перестало быть полем а стало чето-то делать.

Тогда я возьму и сделаю свойство field !!! И интерфейс класса не изменится

Цитата(Domestic @ 21.6.2005, 19:41)

myClass.field и заменить все эти вызовы на вызов метода, поскольку field перестало быть полем а стало чето-то делать

Ха! Заменяем на свойство, и можно даже по коду не лазить - имя то не изменилось.

Во, всплыло одно реально положительное свойство - можно легче использовать это все в визуальном редакторе.

Для JavaBeans необходимо использовать определенне соглашения по именованию.
Для пропертей в том виде, в котором они используются в .NET это сделать проще. Нагляднее и более жестко. Там особо не забалуешь. Есть сеттер и геттер. И никаких особых шагов в сторону не сделаешь.

Вот это занятная мысль для меня

Цитата

Тогда я возьму и сделаю свойство field !!! И интерфейс класса не изменится smile

Цитата(arilou @ 21.6.2005, 10:44)

Ха! Заменяем на свойство, и можно даже по коду не лазить - имя то не изменилось.

Вы невнимательно читали. Вам в 99% случаев придется менять название на более подходящее или вообще менять на вызов метода (следуя вашему же правилу использования пропертей). Да и не об этом речь.

Цитата(arilou @ 21.6.2005, 19:43)

Да, давайте уберем свойства и делегаты с событиями, и получим очередной клон Java

Ну вообщем-то по основным идеям .NET - это явный клон JAVA. Там одно гордое описание виртуальной машины и сборщика мусора с поколениями чего стоит.

Цитата(Domestic @ 21.6.2005, 19:41)

Managed язык, претендующий на простоту обязан быть четко формализован

Кем обязан? Есть спецификация языка C#:

Цитата

Properties are an extension of fields and are accessed using the same syntax. Unlike fields, properties do not designate storage locations. Instead, properties have accessors that read, write, or compute their values.

Цитата

A property is a member that provides access to a characteristic of an object or a class. Examples of properties include the length of a string, the size of a font, the caption of a window, the name of a customer, and so on. Properties are a natural extension of fields — both are named members with associated types, and the syntax for accessing fields and properties is the same. However, unlike fields, properties do not denote storage locations. Instead, properties have accessors that specify the statements to be executed when their values are read or written. Properties thus provide a mechanism for associating actions with the reading and writing of an object's attributes; furthermore, they permit such attributes to be computed.

Добавлено @ 19:51

Цитата(AntonSaburov @ 21.6.2005, 19:48)

Ну вообщем-то по основным идеям .NET - это явный клон JAVA.

Не попадайся на провокацию JAVA vs NET в отдельной теме

Цитата(arilou @ 21.6.2005, 19:43)

С таким же успехом можно на ассемблере писать. Хотя нет.

Можно к пылесосу и стиральную машину пределать. Только никому не надо. И можно сделать процессор, у которого будет 3000 команд. Только никому такое количество не нужно.

Может кто-нибудь вспомнить "бритву Оккама" ? Что там написано ?

В первоначальной форме это правило гласит: «Не пытайся объяснить посредством большего то, что можно объяснить посредством меньшего». Позже была предложена формулировка «Не следует умножать сущности без необходимости».

И вообще, возникает такое впечатление, что просто покрывается убогость языка за счет ООП пуризма. Наличие свойств, событий, и делегатов повышает выразительность C#.

Никогда бы не подумал, что буду защищать C# Сам то я к нему от VB.NET перешел

Это сообщение отредактировал(а) arilou - 21.6.2005, 19:55

Цитата(AntonSaburov @ 21.6.2005, 20:52)

В первоначальной форме это правило гласит: «Не пытайся объяснить посредством большего то, что можно объяснить посредством меньшего». Позже была предложена формулировка «Не следует умножать сущности без необходимости».

Знаем-знаем, мудрый Каа

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

Это сообщение отредактировал(а) Дрон - 21.6.2005, 19:57

Цитата(arilou @ 21.6.2005, 19:54)

И вообще, возникает такое впечатление, что просто покрывается убогость языка

Толко что говорил что Java vs NET в отдельной теме. Кроме того проперти использует не только C#.

А выразительность не должна перерастать в переигрывание.

Вот я нашел для себя пока одно реальное удобство - в визуальном редакторе использование пропертей IMHO более удобно. Не надо думать о правилах именования для тех же JavaBeans.

Но минусов вижу несколько больше.
Добавлено @ 20:00

Цитата

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

Никто не пытается убрать те элемены, которые реально необходимы. Просто здесь попытка выяснить - для чего же все-таки проперти реально нужны. Если только для удобства чтения кода, то это удобство IMHO достаточно сомнительное.

Реально в классах есть данные и операции. Для операций - методы, для данных - свойства, чтобы не нарушать инкапсуляцию. Что тут непонятного?

Цитата(arilou @ 21.6.2005, 21:02)

Реально в классах есть данные и операции. Для операций - методы, для данных - свойства, чтобы не нарушать инкапсуляцию. Что тут непонятного?

Во! Коротко и ясно

Цитата(arilou @ 21.6.2005, 20:02)

Для операций - методы, для данных - свойства, чтобы не нарушать инкапсуляцию.

Ну и зачем тогда

Код

DataSet.Open; ... DataSet.Close;

и кроме этого иметь возможность делать

Код

Active := True; ... Active := False;

Если сделать для себя критерий - если я собираюсь менять данные, то нужны проперти, а если буду что-то делать, то методы - то он рушится при попытке сделать кроме смены значения еще что-то, потому как порождает еще какое-то ДЕЙСТВИЕ. А значит это фактически просьба к объекту - сделай что-нибудь. По сути вызов метода.

Одно то, что часто идет дублирование пропертей и методов говорит о том, что к этому понятию отношение очень разное. И неоднозначное. А неоднозначность не очень хорошее дело.

Если мы говорим о том, что проперть - это чистый сеттер и геттер и только из-за инкапсуляции мы прячем это поле. И может быть когда-нибудь нам неожиданно потребуется добавить еще что-то, то опять мы упираемся в то, что это по сути - методы. Просто вызов их несколько иной.
И из-за несколько отличного синтаксиса нам это преподносится как величайшее достижение ООП ? Овчинка вообщем-то выделки не стоит IMHO.

Цитата(arilou @ 21.6.2005, 11:02)

Реально в классах есть данные и операции. Для операций - методы, для данных - свойства, чтобы не нарушать инкапсуляцию. Что тут непонятного?

Ну и кому от этого легче? Программисту вообще то должно быть глубоко все равно, что он меняет, свойство ли, или там накручено двести строк кода. И опять таки, что в этом принципиально иного по сравнению с setSpeed?

Цитата(AntonSaburov @ 21.6.2005, 11:09)

Если мы говорим о том, что проперть - это чистый сеттер и геттер и только из-за инкапсуляции мы прячем это поле. И может быть когда-нибудь нам неожиданно потребуется добавить еще что-то, то опять мы упираемся в то, что это по сути - методы. Просто вызов их несколько иной. И из-за несколько отличного синтаксиса нам это преподносится как величайшее достижение ООП ? Овчинка вообщем-то выделки не стоит IMHO.

Согласен.

Цитата(AntonSaburov @ 21.6.2005, 21:09)

И из-за несколько отличного синтаксиса нам это преподносится как величайшее достижение ООП

Дык, никто же не заставляет

Другое дело, что это действительно удобная вещь. Просто удобная

Никто не говорит о том, что это что-то революционное и т.п. Это только очень приятное и очень естественное дополнение языка.

Знаете как в C++ Builder были реализованы проперти?

Код

AnsiString __fastcall GetCapt();      void __fastcall SetCapt(AnsiString Caption);      __property AnsiString Caption = { read = GetCapt, write = SetCapt };

Т.е. были методы get и set -- доступные по отдельности. И было дополнение -- позволяющее их объединить.

Странно, вообще-то, от программистов слышать такое яростное отрицание чего-либо

Это сообщение отредактировал(а) Дрон - 21.6.2005, 22:04

Цитата

Странно, вообще-то, от программистов слышать такое яростное отрицание чего-либо smile

Ты просто яростного отрицания не видел Никто ж тут не рвет на себе тельняшку и с пеной у рта не доказывает, что проперти - это зло, плохо, и т п. Это обсуждение некой фичи языка, которое, по моему мнению, не является каким-либо достижением, т.к. его удобство компенсировано тем, что оно "загрязняет" язык. Так же как и индексеры. Вспомни, из чего все пошло - я упомянул, что по моему впечатлению, декларативные языки остановились в развитии и дальнейшие перемены сводятся к игре с синтаксисом. КАк примеры я привел пропертя и индексеры.
ИМХО же сводится к тому, что вводить их не стоило; но раз они есть - флаг им в руки, если придется писать на шарпе я буду их пользовать как велит партия и правительство. Но ведь и пофилосовствовать нужно .

Цитата(Domestic @ 21.6.2005, 23:24)

я упомянул, что по моему впечатлению, декларативные языки остановились в развитии и дальнейшие перемены сводятся к игре с синтаксисом.

А что означает "развитие" для декларативных языков? Когда в последний раз что-либо развивалось?

Цитата(Domestic @ 21.6.2005, 23:24)

ИМХО же сводится к тому, что вводить их не стоило; но раз они есть - флаг им в руки, если придется писать на шарпе я буду их пользовать как велит партия и правительство.

Если тебе это будет глубоко противно - лучше не используй
На шарпе никто ещё не запрещал юзать методы типа getSpeed()/setSpeed().
Добавлено @ 08:09

Цитата(Domestic @ 21.6.2005, 19:47)

Цитата Тогда я возьму и сделаю свойство field !!! И интерфейс класса не изменится smile Цитата(arilou @ 21.6.2005, 10:44) Ха! Заменяем на свойство, и можно даже по коду не лазить - имя то не изменилось. Вы невнимательно читали. Вам в 99% случаев придется менять название на более подходящее или вообще менять на вызов метода (следуя вашему же правилу использования пропертей). Да и не об этом речь.

Кстати, можно подробнее объяснить, где тут противоречие?

Спросил потому, что согласен на все 100% с высказыванием по поводу простоты при замене field на property.

Цитата(mr @ 21.6.2005, 23:06)

Кстати, можно подробнее объяснить, где тут противоречие? Спросил потому, что согласен на все 100% с высказыванием по поводу простоты при замене field на property.

Ну это ж не стандартная процедура, скорее просто пример почему паблик поля это плохо. И проперти явно не были придуманы с мыслью о подобной ситуации.
К тому же большая вероятность того, что пришлось бы заменять обращение к паблик полю на метод, или просто даже проперти назвать по-другому, - тогда все равно нужно искать все обращения к полю.

Хочу пояснить свою мысль насчет данных и операций.

Мы все знаем, что классы были придуманы для того, чтобы объединить в одном месте данные и методы для их обработки. С усложнением программерских задач, данные стали, если можно так выразиться, более гетерогенными. Т.е. сейчас у нас классы оперируют не только внутренними данными, но и внешними, взятыми из других источников.

К чему я это говорю? Мне кажется, что понятие "свойство" более точно описывает те данные, которые класс выставляет наружу независимо от их происхождения. Безусловно, можно сделать getSpeed и setSpeed, можно сделать св-во Speed, разницы не будет. В мире .NET считается, что надо использовать свойства. Пословицу про свой устав в чужом доме помните?

Цитата(AntonSaburov @ 21.6.2005, 20:09)

Если сделать для себя критерий - если я собираюсь менять данные, то нужны проперти, а если буду что-то делать, то методы - то он рушится при попытке сделать кроме смены значения еще что-то

Так никто ж не запрещает использовать методы, там где это оправдано. Я предлагаю привести пример, где ты не можешь решить, что использовать, и вместе разберемся.
Добавлено @ 11:22

Цитата(Domestic @ 22.6.2005, 08:59)

И проперти явно не были придуманы с мыслью о подобной ситуации.

MS пишет, что свойства дают возможность реализовать вычисляемые поля. Только не говори, что методы тоэе могут это сделать Могут. Но предлагается использовать свойства, если по смыслу получается, что возвращается вычисленное значение поля.

Цитата(arilou @ 22.6.2005, 02:21)

В мире .NET считается, что надо использовать свойства.

Дык вопрос-то был о том, почему так считается. Возьми любой класс, и замени все проперти на соответствующие методы. (Я имею в виду написанный тобой класс, а не FCLьный) Поменяется логика работы класса? С ним станет сложнее работать, придется как-то серьезно редизайнить код ? Отнюдь, все будет абсолютно так же как и было до этого. Оттого что написано a.Size = ... вместо a.setSize(...) - разве мне стало понятнее (или непонятнее)?
Вот и интересно, зачем так. Что выиграно? И Size = и в setSize - программист все равно должен для начала почитать доки и разобраться что делает метод/своиство. И в любом случае он будет знать что меняется некая характеристика объекта.

Цитата(arilou @ 22.6.2005, 02:21)

Пословицу про свой устав в чужом доме помните?

Вообще-то не программисты для языка, а язык для программиста. Если я учу язык, я хочу понять, что к чему и зачем. И вполне имею право иметь свое мнение.

Черт, жалко.... Уходил на защиту диплома, такие дебаты проворонил...
Ладно, вроде все прочитал... Не буду возвращатся к самым верхним постам. Так что вклиниваюсь в самый конец.

Цитата(Domestic @ 21.6.2005, 09:12)

Потому, что это принятая в ООП терминология.

Вспоминая дядюшку Бутча.... На ровне с понятием сообщение есть и понятие операция, причем эти термины употребляются в книге как синонимы. Ну даже если были бы только одни сообщения... То чем тебе не нравится такое сообщение, как "Field = 2", где Field - это свойство?! Нигде же не регламентировано, каким образом должны описываться эти сообщения. Так что, я думаю, что использование свойств не выходит за рамки ООП.

Лично я представляю свойство в контексте С# таким образом, свойство - это интерфейс между полями объекта и внешними объектами. Важно отношение один-ко-многим: свойство-поля, а не только строго одно поле. Следуя такому пониманию, у меня никогда не возникает вопроса, когда использовать свойство, а когда метод.

Добавленно позже
Мда, видимо еще не все прочитал. Фигня вышла. Извиняюсь за "вклиниваюсь в самый конец".

Это сообщение отредактировал(а) Tomcat - 23.6.2005, 10:49

Цитата(Domestic @ 22.6.2005, 20:30)

Дык вопрос-то был о том, почему так считается. Возьми любой класс, и замени все проперти на соответствующие методы.

Скобки придется поставить после каждой...

Цитата(Domestic @ 22.6.2005, 20:30)

И в любом случае он будет знать что меняется некая характеристика объекта.

Только если понятние название метода. Мое мнение, со св-вом такого вопроса не возникает. Априори понятно, что изменяя свойство, изменяешь хар-ку объекта.

Вот ты привел определение "A property is a member that provides access to a characteristic of an object or a class. "

Смотрим определение слова "characteristic":

Цитата

Some individualistic feature, attribute, etc. that serves to identify and 'characterize' something. Generally used synonymously with "trait" in discussion of personality... A feature that helps to identify, tell apart, or describe recognizably; a distinguishing mark or trait.... any distinct property or attribute of a product, process or service that can be described and measured to determine conformance or nonconformity to specified requirements...

ну и так далее, вроде понятно. Теперь берем DataTable класс и его своиства Columns, Rows. Да, таблица состоит из столбцов или рядов. Точно также я состою из 2 рук, двух ног и т д. Но мои руки не являются моей характеристикой. Количество рук - да, но рука является моей составляющей, никак не моим индивидуальным свойством. Руль илисиденье не есть характеристики машины, это ее части.
Почему тогда Микрософт, чье определение свойств ты привел, на деле сам себе противоречит? Или его программисты сами не понимают что такое свойство?

Хотелось все-таки услышать оценку моей идеи по поводу визуальности - свойства удобно использовать в визуальных редакторах. Но что-то никто не обсудил это действительно реальное удобство

Нет никаких соглашений по именованию - все достаточно жестко.
Правда опять же все легко работает и в варианте JavaBeans если только соблюдать правила именования.

Цитата(AntonSaburov @ 23.6.2005, 10:04)

Хотелось все-таки услышать оценку моей идеи по поводу визуальности - свойства удобно использовать в визуальных редакторах. Но что-то никто не обсудил это действительно реальное удобство smile

По-моему, именно этим и руководствовались при решении - сделать метод или своиство. Хотя можно было бы например использовать аттрибуты, скажем

Код

[VisualStudioProperty(Name = "Columns")] public DataColumnCollection getColumns() {    // blah blah blah }

Цитата(Domestic @ 23.6.2005, 18:58)

that can be described and measured to determine conformance or nonconformity to specified requirements...

Вот это очень широкое определение, под которое руки и ноги тоже подпадают. С одной стороны, это твои характеристики, которые определяют, являешься ли ты антропоидной сущностью, или нет С другой строны, это составные части тебя как организма.

Тоже самое и с Rows и Columns, с одной стороны, они отличают один DataTable от другого. Со второй стороны - являются частями его самого.

Цитата(AntonSaburov @ 23.6.2005, 19:04)

Хотелось все-таки услышать оценку моей идеи по поводу визуальности - свойства удобно использовать в визуальных редакторах.

Я согласен, с Intellisense всегда видно, свойство это или поле. Т.е. никто не спорит

Цитата(arilou @ 23.6.2005, 10:39)

Вот это очень широкое определение, под которое руки и ноги тоже подпадают. С одной стороны, это твои характеристики, которые определяют, являешься ли ты антропоидной сущностью, или нет smile С другой строны, это составные части тебя как организма.

Нет, характеристика не может объектом, это некое свойство предмета, но не предмет. Например, если тебя попросят описать твою машиму, ты что, пойдешь, вытащишь двигатель, принесешь и скажешь: вот характеристика моей машины? Характеристики машыны - это ее цвет, марка, тип, мощность двигателя, количество дверей, тип кузова, и т п. Но сами по себе цвет или объем движка не являются самостоятельными сущностями.
Когда читаешь table.Columns естественнее полагать, что это количество столбцов, чем сами столбцы. Тогда да, это подпадало бы под определение. А так - нет. Вот и получается, что Микрософт сам не следует своим рекомендациям.