День добрый всем.

По следам вот этого обсуждения "Свойства в С++

Автор: Денис Майдыковский
Дата: 20.11.01

" возник вопрос. А зачем все это вообще надо (кроме ActiveX и VCL)?

Получается:

1) Придумали правило, что не хорошо обращаться к memebers напрямую, а надо писать get_XXX и put_XXX методы.

2) Теперь придумали properties, которые выглядят как memebers, но реально вызываются get_XXX/put_XXX методы. Т.е. мало того, что это "хак" для правила выше, так еще и визуально путает.

Итого: получается что сначала придумали себе правило, а после как его обойти.

Или я чего-то не понимаю?

PS: Сам использую несколько define, которые автоматом создают get_XXX/put_XXX.
Получаются строки вроде
DECLARE_PROPERTY (protected, bool, m_bEditable, Editable)

Свойства инкапсулируют лучше.

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

Здравствуйте, Doc, Вы писали:

Doc>PS: Сам использую несколько define, которые автоматом создают get_XXX/put_XXX.
Doc>Получаются строки вроде
Doc>DECLARE_PROPERTY (protected, bool, m_bEditable, Editable)
В простом случае оно и не надо. get/put нужно для проверки (на корректность при put, что может делать get мне не понятно, т.к. если что-то вычислять — то тогда надо явно функцию оформлять).

Здравствуйте, IceStudent, Вы писали:

IS>В простом случае оно и не надо.

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

Здравствуйте, begray, Вы писали:

B>Свойства инкапсулируют лучше.

Может я не так выразился, но я не сравнимаю обращение через методы и напрямую (считаю что должно быть через методы).
Я говорю именно о properties против обычных методов. В чем тайный смысл создания такого огорода в большинстве классов. Ну в ActiveX и VCL мне понятно — для редакторов. А дальше?

B>То есть в будущем мы легко сможем вставить синхронизацию обращений или подсчет этих самых обращений или еще что-нибудь.

И с обычными put_XXX/get_XXX это легко делается.

Здравствуйте, Doc, Вы писали:

Doc>Не думаю, что стоит делать обращение напрямую к переменным. IMHO все же класс должен "общаться с миром" через методы.
Почему? Если они только и делают, что возвращают и устанавливают эти переменные?

Здравствуйте, Doc, Вы писали:

Doc>И с обычными put_XXX/get_XXX это легко делается.
Для удобства.

Здравствуйте, IceStudent, Вы писали:

IS>Почему? Если они только и делают, что возвращают и устанавливают эти переменные?

Потому что IMHO класс должен скрывать детали свой реализации от внешнего мира.
Ну а если стоит вопрос скорости — можно эти put/get сделать inline.

Здравствуйте, IceStudent, Вы писали:

IS>Здравствуйте, Doc, Вы писали:

Doc>>И с обычными put_XXX/get_XXX это легко делается.
IS>Для удобства.

В чем удобство первой строки от второй

pMyClass->nValue = 5;
pMyClass->put_nValue (5);

В первом случае (для С++)
— лишние обертки, которые нужны только для такой записи и не участвую в работе программы.
— строку можно прочитать двояко: прямое обращение к member или неявый вызов метода.

Здравствуйте, IceStudent, Вы писали:

IS>Здравствуйте, Doc, Вы писали:

Doc>>Не думаю, что стоит делать обращение напрямую к переменным. IMHO все же класс должен "общаться с миром" через методы.
IS>Почему? Если они только и делают, что возвращают и устанавливают эти переменные?

Попробуй — ка в отладчике засечь момент изменения переменной, если с ней общаешься напрямую
Или в определенный момент поменять поведение с "возвращают и устанавливают" на что-то более сложное -- по всему коду будем ползать?

Здравствуйте, Doc, Вы писали:

Doc>В первом случае (для С++)
Doc>- лишние обертки, которые нужны только для такой записи и не участвую в работе программы.
Они могут проверять значение на корректность, например.

Doc>- строку можно прочитать двояко: прямое обращение к member или неявый вызов метода.
Эти подробности знать не обязательно. У тебя есть интерфейс, реализация скрыта. Всё. Так же, как ты, например, не знаешь (не должен знать), что в GetCurrentProcess().

Здравствуйте, Nose, Вы писали:

N>Попробуй — ка в отладчике засечь момент изменения переменной, если с ней общаешься напрямую
Hardware break on memory write

N>Или в определенный момент поменять поведение с "возвращают и устанавливают" на что-то более сложное -- по всему коду будем ползать?
Согласен.

Здравствуйте, IceStudent, Вы писали:

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

Т.е. по вашему properties могут проверять значение на корректность, а методы нет? Бред!

Здравствуйте, IceStudent, Вы писали:

N>>Попробуй — ка в отладчике засечь момент изменения переменной, если с ней общаешься напрямую
IS>Hardware break on memory write

Т.е. это проще чем поставить точку останова?

Это не хак, это — syntactic sugar. Т.е. вопрос удобства использования.

Здравствуйте, Draqon, Вы писали:

D>Это не хак, это — syntactic sugar. Т.е. вопрос удобства использования.

Да назовите как угодно Вопрос в том, в чем удобство записи вида
myClass->nValue = 5;
перед
myClass->put_nValue (5);

Причем первый вариант IMHO не только путает, но и несет накладные расходы.

Здравствуйте, Doc, Вы писали:

[]

Для врапперов COM-объектов. Если там уж есть свойства и методы, то должны быть и при обращении с ними использоваться свойства и методы.

Ну, вот написал я тут на досуге врапперры для MSXML, используя __declspec(property). Так теперь спокойно пишу типа так:

XmlNode node = doc.DocumentElement.ChildNodes.Item(0).LastChild;

Что, по моему, гораздо лучше портянок с многочисленными присваиваниями. Причем вместо проверок HRESULT сделал throw — так и приятнее, и проще — сунул все в try...catch и радуешься жизни.

Не спорю, есть возможность и такого:

XmlNode node = doc.get_DocumentElement().get_ChildNodes().get_Item(0).get_LastChild();

(компилятор так и раскрывает этот __declspec — через call, естественно). Однако, первый вариант более нагляден.
Да и не хочу я писать лишние четыре буквы и две скобки.


Да, господа! С помощью указанной в статье реализации такого не сделать (по крайней мере, у меня не вышло) — все работает только для простых типов, а вот тот же std::string в качестве типа свойства сложно использовать, например, это не сработает:

MyObject.stringProperty.c_str();

Надо только так обходиться:

string s = MyObject.stringProperty;
s.c_str();

Может, кто уже решил сию проблему, а то как-то на __declspec — Microsoft specific, все-таки.

Здравствуйте, denaturat, Вы писали:

D>Для врапперов COM-объектов. Если там уж есть свойства и методы, то должны быть и при обращении с ними использоваться свойства и методы.

Насколько мне известно, как раз идеология COM запрещает прямые обращения к mamabers — только через методы.
Properties к COM можно отнести в виду использования ActiveX (как частный случай COM). Вот тут согласен, properties для ActiveX самый подходящий выход — вместо обращения к members напрямую через обертки. В остальном — смыла нет. Ну или пока аргументов достаточных я не видел.

Здравствуйте, Doc, Вы писали:

Doc>Да назовите как угодно Вопрос в том, в чем удобство записи вида
Doc>myClass->nValue = 5;
Doc>перед
Doc>myClass->put_nValue (5);

Doc>Причем первый вариант IMHO не только путает, но и несет накладные расходы.

Для большинства людей это естественный синтаксис для присваивания переменной значения.

Здравствуйте, AndrewJD, Вы писали:

AJD>Для большинства людей это естественный синтаксис для присваивания переменной значения.

Очень жаль