. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
ME>Вот здесь разжевано, чем плохи свойства: C++ Properties -- a Library Solution
ME>-- ME>Maxim Yegorushkin
Нет ни одного аргумента. Только ссылка на мнение неких безымянных "экспертов".
Шахтер wrote:
> ME>Вот здесь разжевано, чем плохи свойства: C++ Properties -- a Library Solution > > Нет ни одного аргумента. Только ссылка на мнение неких безымянных "экспертов".
Лично для меня мнение эксперта — аргумент.
Вообще, я не вижу как property могут сделать мой код более элегантным, понятным, кратким и эффективным.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
SDB>В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса.
Чем хуже будет так :
class Window
{
int _width;
public:
int get_width() { return _width; }
void set_width(int width) { _width=width; MoveWindow(...); }
};
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, LaptevVV, Вы писали:
LVV>>В чем отличие от простых полей? Я на дельфях не писал.
G>Может в том, что можно при чтении/записи выполнять валидацию данных, какие-нить дополнительные действия по изменению состояния объекта ну и т.п. И в конце концов сами данные остаются скрытыми и могут быть изменены тока через паблик интерфейс. Хотя чем не угодили гетеры/сетеры — не понятно.
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
Простые публичные поля нарушают инкапсуляцию.
Свойства позволяют работать с инкапсулированными данными как с обычными полями (с синтаксической точки зрения), но при этом инкапсуляция полностью сохранена, так как все происходит через операции get/set.
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, SchweinDeBurg, Вы писали:
SDB>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>Прочитал я тут статью Дениса Майдыковского
. Статья хорошая. Только один вопрос меня интересует: а нафига свойства нужны? В чем их прелесть? В чем отличие от простых полей? Я на дельфях не писал.
SDB>>В том, что при чтении/записи значения можно выполнить произвольные действия (помимо собственно обращения к полю). Например, класс "окно" может иметь свойство "ширина", при назначении значения которого вызывается ::MoveWindow(). ИМХО — красота подобного решения это дело вкуса. :)
__>Чем хуже будет так : __>
Здравствуйте, _nn_, Вы писали:
__>Мне кажется вызов функции более нагляден чем свойство.
я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так".
Вроде, ответил...
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, _nn_, Вы писали:
__>>Мне кажется вызов функции более нагляден чем свойство. J>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>Вроде, ответил...
Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
Здравствуйте, ssm, Вы писали:
ssm>Здравствуйте, jazzer, Вы писали:
J>>сравни:
J>>
J>>a.x++;
J>>
J>>и
J>>
J>>int x = a.get_x();
J>>x++;
J>>a.set_x(x);
J>>
ssm>сравни:
ssm>
ssm>a.incAltitude();
ssm>and
ssm>a.x++;
ssm>
1. Altitude — это какое-то новое слово (в смысле, легко можно скатить в обсуждение смысловой составляющей кода, хотя изначально речь не об этом)
2. А как насчет:
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, _nn_, Вы писали:
__>>>Мне кажется вызов функции более нагляден чем свойство. J>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>Вроде, ответил...
__>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
совершенно верно.
а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями.
эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, _nn_, Вы писали:
__>>>>Мне кажется вызов функции более нагляден чем свойство. J>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>>Вроде, ответил...
__>>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
J>совершенно верно. J>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями. J>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется)
Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна
если дело только в инкременте :)
а вообще дело я так понимаю не в одном инкременте и полезность этих проперти вылазит на ваш взгляд когда часто используешь их...
Тут я согласен...
:) Но разве что в том почему вам так кажется...
На самом деле если копнуть... То если вам часто требуется использовать этот проперти, то элегантней создать кеширующую переменную :) и с ней играться:
и красивее и понятней и вызовов меньше...
чем если:
a.x++;
a.x = a.y + b.x;
...
согласен кода меньше... а внутри? :) вызовы методов...
Сейчас мне конечно скажут, что то аля : "В то время когда производительность процессоров ..." :)
Простота не всегда достигается просто...
С уважением Denys Valchuk
IMHO чем больше мнений тем оптимальней выбор варианта... :)
class X
{
public:
operator++()...
...
}
class A
{
public:
property x(type "X" get="getX" set="setX")
}
я немного не то хотел показать, сут в том,
что оператор инкремента и т.д. обрабатываются в обектах класса Х, а только после этого
происходит установка для агригируемого обекта в екземпляре класса А. При заведении метода
выражаюшего действия над обектом класса А будет суть операции понятней. В твоем примере:
++а.х;
--а.х;
а.х--;
обект класса А не получает вообше никаких уведомлений о измемении агрегата, поэтому приведенное тобой сравнениe
а.х++;
и
int х = а.get_х();
х++;
а.set_х(х);
совершенно не равназначны, в первом случае мы просто нарашиваем значение агрегата, а во втором мы даем обекту а
информазию о изменении агрегата
Ну а что мешает возвратить из метода get ссылку на переременную-член класса? Кроме того, логичнее и правильнее было бы реализовать два метода: один возвращает ссылку, а другой константную ссылку или копию переменной. Тогда в коде программы было бы видно зачем данная переменная член используется в данном месте и позволяло избежать глупых ошибок когда переменная-член в каком-то сложном выражении неожиданно изменяет свое значение.
А>Ну а что мешает возвратить из метода get ссылку на переременную-член класса? Кроме того, логичнее и правильнее было бы реализовать два метода: один возвращает ссылку, а другой константную ссылку или копию переменной. Тогда в коде программы было бы видно зачем данная переменная член используется в данном месте и позволяло избежать глупых ошибок когда переменная-член в каком-то сложном выражении неожиданно изменяет свое значение.
А как отслеживать изменения ?
class X
{
int x;
public:
int& get_x() { return x; }
};
X a;
a.get_x()=3; // как узнаем что x изменился ?
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Glоbus, Вы писали:
G>>Здравствуйте, LaptevVV, Вы писали:
J>Очень просто.
J>сравни:
J>
J>a.x++;//вот читаю я код и задаюсь вопросом - это открытое поле класса или свойство
J> J>и
J>
J>int x = a.get_x();
J>x++;
J>a.set_x(x);
J>
То есть не хочу разводить войну насчет пропертей, но саттер писал, что выбор надо делать в пользу прозрачности и понятности кода, и я лично с ним согласен. По моему субъективному мнению единственный недостаток пропертей — это именно неоднозначость при чтении кода.
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, _nn_, Вы писали:
__>>>Здравствуйте, jazzer, Вы писали:
J>>>>Здравствуйте, _nn_, Вы писали:
__>>>>>Мне кажется вызов функции более нагляден чем свойство. J>>>>я же не с этим утверждением спорил, а отвечал на твой вопрос "Чем хуже будет так". J>>>>Вроде, ответил...
__>>>Я просто хочу сказать, что и в случае свойства и в случае функции нужно будет все отслеживать, следовательно разница только в работе извне, точнее как это выглядит.
J>>совершенно верно. J>>а отслеживать вообще ничего не надо, независимо от выбора между свойствами и функциями. J>>эта внутренняя переменная просто не нужна, все должно делаться через MoveWindow и GetWidth (или как там соответствующая функция API называется) __>Так ведь внутри есть какая-то переменная, которая меняется, так что переменная нужна :)
А откуда она взялась?
Имхо, в данном случае свойство должно реализовываться непосредственно через АПИ, без промежуточных переменных