" возник вопрос. А зачем все это вообще надо (кроме 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 мне не понятно, т.к. если что-то вычислять — то тогда надо явно функцию оформлять).
Здравствуйте, begray, Вы писали:
B>Свойства инкапсулируют лучше.
Может я не так выразился, но я не сравнимаю обращение через методы и напрямую (считаю что должно быть через методы).
Я говорю именно о properties против обычных методов. В чем тайный смысл создания такого огорода в большинстве классов. Ну в ActiveX и VCL мне понятно — для редакторов. А дальше?
B>То есть в будущем мы легко сможем вставить синхронизацию обращений или подсчет этих самых обращений или еще что-нибудь.
Здравствуйте, Doc, Вы писали:
Doc>Не думаю, что стоит делать обращение напрямую к переменным. IMHO все же класс должен "общаться с миром" через методы.
Почему? Если они только и делают, что возвращают и устанавливают эти переменные?
Здравствуйте, 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
Что, по моему, гораздо лучше портянок с многочисленными присваиваниями. Причем вместо проверок HRESULT сделал throw — так и приятнее, и проще — сунул все в try...catch и радуешься жизни.
(компилятор так и раскрывает этот __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 не только путает, но и несет накладные расходы.
Для большинства людей это естественный синтаксис для присваивания переменной значения.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, AndrewJD, Вы писали:
AJD>Для большинства людей это естественный синтаксис для присваивания переменной значения.
Очень жаль
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re: А зачем вообще нужны properties?
От:
Аноним
Дата:
06.09.06 21:15
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Получается:
Doc>1) Придумали правило, что не хорошо обращаться к memebers напрямую, а надо писать get_XXX и put_XXX методы.
Doc>2) Теперь придумали properties, которые выглядят как memebers, но реально вызываются get_XXX/put_XXX методы. Т.е. мало того, что это "хак" для правила выше, так еще и визуально путает.
Doc>Итого: получается что сначала придумали себе правило, а после как его обойти.
Все просто. проперти это явно выраженые публичные данные объекта. Не каждое проперти это обязательно мембер, и не каждая функции возвращает данные ассоциируемые с объектом. Простой пример: в объекте DataRow поля удобнее описать именно как properties.
Здравствуйте, <Аноним>, Вы писали:
А>Все просто. проперти это явно выраженые публичные данные объекта. Не каждое проперти это обязательно мембер, и не каждая функции возвращает данные ассоциируемые с объектом. Простой пример: в объекте DataRow поля удобнее описать именно как properties.
Да, но ведь такой полход идет в разрез с идеологией C++. Или я ошибаюсь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: А зачем вообще нужны properties?
От:
Аноним
Дата:
07.09.06 16:13
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Да, но ведь такой полход идет в разрез с идеологией C++. Или я ошибаюсь?
Есть утверждение что класс должен скрывать детали своей реализации и общаться с миром только через методы. С этой точки зрения properties это хак (т.е. как бы через методы, но вид как работы с members).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[5]: А зачем вообще нужны properties?
От:
Аноним
Дата:
08.09.06 06:18
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, <Аноним>, Вы писали:
А>>В чем?
Doc>Есть утверждение что класс должен скрывать детали своей реализации и общаться с миром только через методы. С этой точки зрения properties это хак (т.е. как бы через методы, но вид как работы с members).
Где это такие утверждения, что только через методы? Свойства это не хак, а способ разделить данные объекта и методы работы с этими данными. Связи с членами самого объекта тут нет, свойство может представлять его, а может и нет.
Здравствуйте, <Аноним>, Вы писали:
А>Где это такие утверждения, что только через методы?
Да сейчас уже и не вспомню. Давно, когда C++ учил, встречал такое в книге. В принципе согласен с данным положением.
А>Свойства это не хак, а способ разделить данные объекта и методы работы с этими данными. Связи с членами самого объекта тут нет, свойство может представлять его, а может и нет.
Это ясно, но я несколько об ином.
Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода?
Причем применительно именно к C++. Ведь это только дает накладные расходы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: А зачем вообще нужны properties?
От:
Аноним
Дата:
08.09.06 07:00
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, <Аноним>, Вы писали:
А>>Где это такие утверждения, что только через методы? Doc>Да сейчас уже и не вспомню. Давно, когда C++ учил, встречал такое в книге. В принципе согласен с данным положением.
Скорее всего ты что-то напутал, в с++ всегда существовали друзья которые получали доступ к приватным членам без всяких методов объекта.
Doc>Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода?
Это не способ записи. Это другая логическая сущность. Выбор способа записи это просто очевидное следствие.
Doc>Причем применительно именно к C++. Ведь это только дает накладные расходы.
Какие? Фактически это разновидность метода без параметров.
Еще раз — я только о обычном С++ говорю. Там где properties были задуманы изначально и есть в языке — другой разговор. Я уже говорил, что есть места (ActiveX, VCL) где они в тему.
А>Скорее всего ты что-то напутал, в с++ всегда существовали друзья которые получали доступ к приватным членам без всяких методов объекта.
Нет, friend это отдельная тема (там более что friend не обязательно для members).
Хотя применительно к теме разговора friend как раз IMHO подтверждает данное правило.
Смотри, напрямую обращаться нельзя (а там более в protected), но вдруг очень надо. Тогда можно объявить friend. Это дает классу возможность контролировать доступ до его members и закрытых методов.
Doc>>Чем такой способ записи (кроме привычки обращаться к полям напрямую) лучше записи в виде метода? А>Это не способ записи. Это другая логическая сущность. Выбор способа записи это просто очевидное следствие.
Вот тут подробнее.
Doc>>Причем применительно именно к C++. Ведь это только дает накладные расходы. А>Какие? Фактически это разновидность метода без параметров.
Небольшие, но есть. Вызов метода это просто вызов метода. Стандартной реализации properties в С++ нет (MS и прочие specific не в счет). Значит для записи вида
myClass.nValue = 5;
надо писать свою реализацию. Например вот — Свойства в С++
.
Там же (в конце статьи) есть и расходах данного примера.
PS: Возможно это дело привычки, но например мне не нравится код, где вместо двух строк ::SendMessage() тянется какой-нибудь CButton. Так и тут — просто ради иной формы записи делается накрутка лишнего кода.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: А зачем вообще нужны properties?
От:
Аноним
Дата:
08.09.06 08:26
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Здравствуйте, <Аноним>, Вы писали:
Doc>Еще раз — я только о обычном С++ говорю. Там где properties были задуманы изначально и есть в языке — другой разговор. Я уже говорил, что есть места (ActiveX, VCL) где они в тему.
Из темы это никак не следует. С стандартном с++ свойст нет, поэтому и обсуждать нечего. Из обсуждения следует, что у тебя претензии к самой концепции свойств, а оказывается у тебя претензии к отдельным ее реализациям, это совсем другое.
Doc>Нет, friend это отдельная тема (там более что friend не обязательно для members).
Какая разница отдельная тема или нет? Есть еще операторы, которые не методы но доступ вполне себе имеют. Слишком много исколючений что бы "только через методы" оставалось верной.
Doc>Вот тут подробнее.
См. первое сообщение. Есть реализация объекта и его представление. Взять тот же DataRow для примера. Как отпределить какие методы есть суть ячейки, а какие работа с ними? Суффиксами и префиксами? А если я получаю сериализованый объект? Парсить названия функуий? Вот для того что бы избежать этого неудобства и используют свойства.
Doc>>>Причем применительно именно к C++. Ведь это только дает накладные расходы. А>>Какие? Фактически это разновидность метода без параметров.
Doc>Небольшие, но есть. Вызов метода это просто вызов метода. Стандартной реализации properties в С++ нет (MS и прочие specific не в счет). Значит для записи вида
12 байт в одтельной взятой реализации конечно жуткие расходы.
Здравствуйте, <Аноним>, Вы писали:
А>Из темы это никак не следует.
См.
— первое сообщение темы (там ссылка на обсуждение статьи. собственно именно по этому и вопрос).
— название раздела форума (было бы странно тот говорить про C# или даже про C++ Builder)
A> а оказывается у тебя претензии к отдельным ее реализациям, это совсем другое.
Именно. Хочу понять в чем сахар прикручивания properties к C++.
Doc>>Нет, friend это отдельная тема (там более что friend не обязательно для members). А>Какая разница отдельная тема или нет?
Странный вопрос. Повторю — объявление friend подразумевает что обе стороны знают что делают и куда лезут. А вот вынос member в public только добавляет гимороя в дальнейшем развитии класса.
А>12 байт в одтельной взятой реализации конечно жуткие расходы.
А если у вас 50 properties и все это еще в N копиях
Хотя я и не утвеждал что жуткие. Но я уже писал, что не понимю людей которые вместо ::SendMessage () создают классы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: А зачем вообще нужны properties?
От:
Аноним
Дата:
08.09.06 09:49
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>- название раздела форума (было бы странно тот говорить про C# или даже про C++ Builder)
Зато вполне можно говорить о c++/cli
A>> а оказывается у тебя претензии к отдельным ее реализациям, это совсем другое.
Doc>Именно. Хочу понять в чем сахар прикручивания properties к C++.
В пятый раз. В явном отделении даннах которые представляет объект от фунукций. Имхо ты не понять хочешь, а доказать, что без низ можно обойтись. Можно. Как и без классов, только зачем? Это ж интсрумент, а не набор догматов, если у молотка более удобная ручка, то почему бы им не пользоваться?
Doc>>>Нет, friend это отдельная тема (там более что friend не обязательно для members). А>>Какая разница отдельная тема или нет?
Doc>Странный вопрос. Повторю — объявление friend подразумевает что обе стороны знают что делают и куда лезут. А вот вынос member в public только добавляет гимороя в дальнейшем развитии класса.
А при чем тут мемберы? Публичные члены и доступ к членам "только через функции" утверждения разные.
Не говоря уж о том, что речь идет о свойствах, которые могут быть не связаны ни с одним из членом, публичные они там или нет. members это для объекта, properties для пользователя объекта. Так что мухи отдельно, котлеты отдельно.
А>>12 байт в одтельной взятой реализации конечно жуткие расходы.
Doc>А если у вас 50 properties и все это еще в N копиях Doc>Хотя я и не утвеждал что жуткие. Но я уже писал, что не понимю людей которые вместо ::SendMessage () создают классы.
Все зависит от задачи. Если надо запомнить состояние, то лучше создать класс, чем плодить дурацкие переменные для глобальной ::SendMessage(). Гибче надо быть...
Здравствуйте, <Аноним>, Вы писали:
А>Зато вполне можно говорить о c++/cli
Подловил
А>В пятый раз. В явном отделении даннах которые представляет объект от фунукций. Имхо ты не понять хочешь, а доказать, что без низ можно обойтись.
Как раз нельзя. Пример тому тот же VCL и опять же ActiveX. Ну такова его изначальная природа, что properties сами простяся для работы с design-time редактором. В этом случае такая огранизация вполне оправдана. А вот ради чего городить городушки как в приведенной статье... ?
А>А при чем тут мемберы? Публичные члены и доступ к членам "только через функции" утверждения разные.
Ты сбился. Погляди разговор с своего сообщения. Это к вопросу об утверждении "доступ к членам только через функции". К этой части текста properties ни каким боком (разьве только что их стиль записи как раз похож на этот неправильный подход).
А>Все зависит от задачи. Если надо запомнить состояние, то лучше создать класс, чем плодить дурацкие переменные для глобальной ::SendMessage(). Гибче надо быть...
Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: А зачем вообще нужны properties?
От:
Аноним
Дата:
08.09.06 14:40
Оценка:
Здравствуйте, Doc, Вы писали:
Doc>Как раз нельзя. Пример тому тот же VCL и опять же ActiveX. Ну такова его изначальная природа, что properties сами простяся для работы с design-time редактором. В этом случае такая огранизация вполне оправдана. А вот ради чего городить городушки как в приведенной статье... ?
Обойтись можно.
Я так понимаю претензии именно к реализации? Ну так ее тебя никто силком не заставляет использовать.
Doc>Ты сбился. Погляди разговор с своего сообщения. Это к вопросу об утверждении "доступ к членам только через функции". К этой части текста properties ни каким боком (разьве только что их стиль записи как раз похож на этот неправильный подход).
Это ты сбился, я сомневаюсь, что где либо декларирован принцип, что доступ к членам должен быть только через функции. Не больше не меньше. Соотвественно и объявлять что либо корректным/некорректным на основании неверного утверждения тоже не верно.
Doc>Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние.
классу нет нужды делать внешнуюю переменную. в результате будет одна необходимая сущность вместо двух, к тому же не связанных.
Здравствуйте, <Аноним>, Вы писали:
А>Обойтись можно. А>Я так понимаю претензии именно к реализации? Ну так ее тебя никто силком не заставляет использовать.
В первую очередь, я не доказываю что их не надо использовать, а наоборот спрашиваю в чем сахар. Может я туплю Пока явного выйгрыша использования в "обычном" С++ не увидел.
Ладно, я понимаю. Пятница вечер ... все устали давай завяжем.
А>Это ты сбился, я сомневаюсь, что где либо декларирован принцип, что доступ к членам должен быть только через функции. Не больше не меньше. Соотвественно и объявлять что либо корректным/некорректным на основании неверного утверждения тоже не верно.
Хорошо, давай пойдет методом "от противного". Приведи пример, когда использования прямого доступа будет благом сейчас и в дальнейшем. Причем речь не о firend сущности (т.е. класс и обращающийся к нему объет неичего не знают о особенносиях внутренностей друг-друга).
Doc>>Не думаю что открою Америку, но сей класс как раз и сделать переменную и запишет туда состояние. А>классу нет нужды делать внешнуюю переменную. в результате будет одна необходимая сущность вместо двух, к тому же не связанных.
Зачем классу внешняя переменная? Он заведет внутреннюю. Итого имеем:
1) просто переменную + 2 строки кода
2) ту же переменную внутри класса, но уже сам класс в довесок и как минимум еще вызовы конструктора и деструктора. Огород на пустом месте.
Свойства это не хак, а способ разделить данные объекта и методы работы с этими данными. Связи с членами самого объекта тут нет, свойство может представлять его, а может и нет.
