Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

D_KEY, блин, да посмотри ты на мой пример. Вот свойство формы: ActiveControl. Сеттер этого свойства (кто бы мог подумать) просто присваивает ссылку на новый активный контрол. Если мы у активного контрола что-то меняем, что, сеттер свойства ActiveControl должен вызываться? Думай

Добавлено 27.01.11, 17:17

Цитата D_KEY @ 27.01.11, 17:17

Я не понимаю, зачем это происходит именно так.

Думай

Добавлено 27.01.11, 17:18

Цитата D_KEY @ 27.01.11, 17:17

Да, и это мне не нравится

Это одинаково и в Джаве, и в Шарпе, и в Дельфи. Да во всех языках со схожей объектной идеологией

Цитата --Ins-- @ 27.01.11, 17:17

Думай

Я подумал. Прокомментируйте мои мысли.

Цитата --Ins-- @ 27.01.11, 17:15

Цитата D_KEY @ 27.01.11, 17:13

А как же инкапсуляция? Вот так взяли и поменяли свойство, не спросив у объекта.

Еще как спросив Только того объекта, чье свойство устанавливается, а это - объект Point, а не Rect

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

Цитата D_KEY @ 27.01.11, 17:19

Но если Point будет не классом, а record, то

...не скомпилируется

Цитата D_KEY @ 27.01.11, 17:19

если мы даем возможность менять состояние атрибута объекта напрямую.

Где напрямую что-то меняется в обход сеттера того свойства, которое мы меняем?

Цитата MyNameIsIgor @ 27.01.11, 17:18

Я подумал. Прокомментируйте мои мысли.

Секунду...

Цитата D_KEY @ 27.01.11, 17:13

А как же инкапсуляция? Вот так взяли и поменяли свойство, не спросив у объекта. Я хотя бы могу как-то вернуть копию объекта(так, чтобы клиенту не пришлось ее явно удалять)? Или это невозможно в принципе?

еще раз, при чем тут инкапсуляция внутреннего объекта? у нас свойство типа TPoint, оно его и возвращает, в интерфейсе TPoint заложено изменение X, какого хрена TRect не должен этого позволять? если хочется, что бы нельзя было изменять внутренний объект, возвращайте из геттера GetPoint новый объект TPoint, а не тот же самый

Цитата D_KEY @ 27.01.11, 17:13

Нет, я возвращаю значение типа const string &

это не суть важно в данном случае.

Сообщение отредактировано: korvin - 27.01.11, 17:22

Цитата --Ins-- @ 27.01.11, 17:17

D_KEY, блин, да посмотри ты на мой пример. Вот свойство формы: ActiveControl. Сеттер этого свойства (кто бы мог подумать) просто присваивает ссылку на новый активный контрол. Если мы у активного контрола что-то меняем, что, сеттер свойства ActiveControl должен вызываться? Думай

Еще раз. Мы не должны позволять менять состояние внутреннего объекта, который "вернуло" свойство, ибо это нарушение инкапсуляции. Ты же мне опять рассказываешь о реализации.

Цитата

Цитата D_KEY @ 27.01.11, 17:17

Я не понимаю, зачем это происходит именно так.

Думай

Думаю.

Цитата

Цитата D_KEY @ 27.01.11, 17:17

Да, и это мне не нравится

Это одинаково и в Джаве, и в Шарпе, и в Дельфи. Да во всех языках со схожей объектной идеологией

Да.

Добавлено 27.01.11, 17:24

Цитата --Ins-- @ 27.01.11, 17:21

Цитата D_KEY @ 27.01.11, 17:19

Но если Point будет не классом, а record, то

...не скомпилируется

И правильно сделает. Почему тут компилируется? Забудь о реализации и расскажи на уровне концепций. Мы всего заменили реализацию типа Point

Цитата

Цитата D_KEY @ 27.01.11, 17:19

если мы даем возможность менять состояние атрибута объекта напрямую.

Где напрямую что-то меняется в обход сеттера того свойства, которое мы меняем?

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

Цитата D_KEY @ 27.01.11, 17:21

Еще раз. Мы не должны позволять менять состояние внутреннего объекта, который "вернуло" свойство, ибо это нарушение инкапсуляции.

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

Сообщение отредактировано: korvin - 27.01.11, 17:25

Цитата korvin @ 27.01.11, 17:21

Цитата D_KEY @ 27.01.11, 17:13

А как же инкапсуляция? Вот так взяли и поменяли свойство, не спросив у объекта. Я хотя бы могу как-то вернуть копию объекта(так, чтобы клиенту не пришлось ее явно удалять)? Или это невозможно в принципе?

еще раз, при чем тут инкапсуляция внутреннего объекта? у нас свойство типа TPoint, оно его и возвращает, в интерфейсе TPoint заложено изменение X, какого хрена TRect не должен этого позволять? если хочется, что бы нельзя было изменять внутренний объект, возвращайте из геттера GetPoint новый объект TPoint, а не тот же самый

Я уже спрашивал, как мне это сделать, не заставив при этом пользователя руками удалять этот новый объект?

Цитата MyNameIsIgor @ 27.01.11, 17:15

Только вот Form нифига не в курсе, что её ActiveControl изменился. В результате накручивают ещё усложнение - свойства с уведомлениями, мы на них подписываемся, получаем сообщения хз откуда, короче, имеет только страшную головную боль вместо того, чтобы цивильно юзать методы, которые говорят "я посылаю тебе сообщение".

Все в курсе те кто надо. Форма отреагирует OnActiveControlChange в том случае, если фокус перешел к другому контролу. Что, должно быть как-то иначе?

Цитата korvin @ 27.01.11, 17:25

Цитата D_KEY @ 27.01.11, 17:21

Еще раз. Мы не должны позволять менять состояние внутреннего объекта, который "вернуло" свойство, ибо это нарушение инкапсуляции.

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

Почему, если у этого объекта тип не является классом, то поведение одно, а если является, то другое?

Цитата

иначе возвращаем копию

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

Цитата D_KEY @ 27.01.11, 17:25

Я уже спрашивал, как мне это сделать, не заставив при этом пользователя руками удалять этот новый объект?

меня вроде не спрашивал, но это бессмысленно, ты же знаешь, что мне нравятся языки с GC, и имено за его отсутствие я буду ругать делфи, но не за ссылочность объектов =)

а так, есть же вроде в делфи то же приписывание объекту владельца, который его удалит, что и в С++, правда нужно наследоваться не от TObject, а ниже по иерархии, что печально, да

Добавлено 27.01.11, 17:29

Цитата D_KEY @ 27.01.11, 17:26

Почему, если у этого объекта тип не является классом, то поведение одно, а если является, то другое?

потому что значения типов не-классов не являются объектами

Сообщение отредактировано: korvin - 27.01.11, 17:30

Цитата --Ins-- @ 27.01.11, 17:25

Все в курсе те кто надо. Форма отреагирует OnActiveControlChange в том случае, если фокус перешел к другому контролу. Что, должно быть как-то иначе?

Да я понимаю, что отреагирует. Я говорю, что свойства в данном случае вносят элемент оверинжинринга - нам надо тщательно подписываться на все события ActiveControl. Вместо того, чтобы иметь методы getActiveControl и setActiveControl.

Цитата korvin @ 27.01.11, 17:25

Цитата D_KEY @ 27.01.11, 17:21

Еще раз. Мы не должны позволять менять состояние внутреннего объекта, который "вернуло" свойство, ибо это нарушение инкапсуляции.

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

Допустим. Но я хочу изменять этот объект в методах класса, а свойство предоставить только для чтения. Как быть? Возвращать копию? А зачем создавать новые объекты? А если это singleton?

Добавлено 27.01.11, 17:35

Цитата korvin @ 27.01.11, 17:28

Цитата D_KEY @ 27.01.11, 17:25

Я уже спрашивал, как мне это сделать, не заставив при этом пользователя руками удалять этот новый объект?

меня вроде не спрашивал, но это бессмысленно, ты же знаешь, что мне нравятся языки с GC, и имено за его отсутствие я буду ругать делфи, но не за ссылочность объектов =)

Мне тоже нравится GC(не во всех задачах, правда). Я не против ссылочной семантики, я против неявного деления переменных на значение/ссылки по виду типа, против отсутствия const.

Цитата

а так, есть же вроде в делфи то же приписывание объекту владельца, который его удалит, что и в С++, правда нужно наследоваться не от TObject, а ниже по иерархии, что печально, да

А разве в Delphi можно сказать этому объекту владельцу, чтобы он вел себя как ссылка или указатель? В С++ умные указатели-владельцы имеют интерфейс указателей(*, -> и т.п.).

Сообщение отредактировано: D_KEY - 27.01.11, 17:35

Цитата MyNameIsIgor @ 27.01.11, 17:30

Вместо того, чтобы иметь методы getActiveControl и setActiveControl.

Не понял как методы тебе помогут в чем-либо? Свойства - это с одной стороны просто сокращенная запись методов

Цитата korvin @ 27.01.11, 17:28

есть же вроде в делфи то же приписывание объекту владельца, который его удалит

Миллион способов автоматического контроля жизни объектов
1. Owner
2. Оборачиваем в интерфейс. Интерфейсы автоматически финализируются
3. Helper к классу TObject позволит просто подключить автоконтроль времени жизни ко всем типам объектов, которые захочешь

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

Добавлено 27.01.11, 17:43

Цитата D_KEY @ 27.01.11, 17:30

А разве в Delphi можно сказать этому объекту владельцу, чтобы он вел себя как ссылка или указатель? В С++ умные указатели-владельцы имеют интерфейс указателей(*, -> и т.п.).

В с++ много чего не по-человечески сделано. А в Delphi можно сказать объекту-владельцу, чтобы он вел себя как объект-владелец, а не то, чем он не является. В древнем Китае желающим странного отрубали голову. Очень мудро

Цитата D_KEY @ 27.01.11, 17:30

Возвращать копию? А зачем создавать новые объекты?

затем, что иначе вернешь тот же самый объект, того же самого типа.