Цитата(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% случаев придется менять название на более подходящее или вообще менять на вызов метода (следуя вашему же правилу использования пропертей). Да и не об этом речь.