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

[Romkin]

Цитата korvin @ 28.10.11, 19:49

нет, только один

method Memo.copyDataFrom (CanGiveCollection<Stringable> anyObject)
clear
addAll(anyObject.items)
end

ОМГ! То есть, вместо набора методов набор объектов извлечения коллекции, я правильно понял? Понятно, что это ООП, но чем это лучше предоставления атрибута в виде объекта-коллекции?

Добавлено 29.10.11, 07:24

Цитата Flex Ferrum @ 29.10.11, 06:28

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

Точно. Я тоже не понимаю, почему скрытие сеттера и геттера нарушает чего-то там.

Цитата Qraizer @ 29.10.11, 04:01

Кстати, мне вот интересно, можно ли в Дельфи обеспечить ОП-шное раздельное наследование аттрибутов при ромбовидной иерархии иначе чем ручным программированием инвариантов? Иначе же минимальной единицей разделения/совмещения является исключительно класс.

В Delphi нет множественного наследования, следовательно и с ромбом разбираться не приходится. А у интерфейсов нет данных (свойства есть, но это всегда геттер/сеттер).

[Qraizer]

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

Сообщение отредактировано: Qraizer - 29.10.11, 08:09

[Romkin]

Цитата Qraizer @ 29.10.11, 08:05

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

Каким образом окажется ромб в интерфейсах? Это принципиально невозможно, у интерфейса нет полей данных и виртуальных методов.

Цитата Qraizer @ 29.10.11, 08:05

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

Ну-ну. Это когда интерфейсы подменяют абстрактными классами - вот тогда траблы имеют место.

[korvin]

Цитата Romkin @ 29.10.11, 07:21

ОМГ! То есть, вместо набора методов набор объектов извлечения коллекции, я правильно понял?

хз, я не понял тебя

Добавлено 29.10.11, 11:37

Цитата Romkin @ 29.10.11, 07:21

Точно. Я тоже не понимаю, почему скрытие сеттера и геттера нарушает чего-то там.

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

Добавлено 29.10.11, 11:56

Цитата Romkin @ 29.10.11, 07:21

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

тем, что не вводит в заблуждение и соответственно не ухудшает читабельность

[Romkin]

Цитата korvin @ 29.10.11, 11:30

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

Доступ к приватному полю через метод - это прямой доступ?

Цитата korvin @ 29.10.11, 11:30

хз, я не понял тебя

Может быть и я не понял твой код. Я не понимаю, как можно связать разнородные объект, не написав под каждый тип свой вспомогательный объект.

Добавлено 29.10.11, 12:57

Цитата korvin @ 29.10.11, 11:30

тем, что не вводит в заблуждение и соответственно не ухудшает читабельность

Свойства улучшают читабельность. Сам же запутался, получаем length, а устанавливаем через resize. Да, никаких заблуждений.

[D_KEY]

Цитата Flex Ferrum @ 29.10.11, 06:28

А потому, если объект сообщает клиенту, что у него есть длина, значит клиент может ее запросить. Или изменить.

Может. С помощью соответствующих методов. Зачем на это нужно наворачивать еще нечто, уменьшающее прозрачность?

Добавлено 29.10.11, 14:35

Цитата Romkin @ 29.10.11, 07:21

Я тоже не понимаю, почему скрытие сеттера и геттера нарушает чего-то там.

А я не понимаю, зачем скрывать сеттеры и геттеры. Ведь это уменьшает прозрачность и ухудшает понимания происходящего. Читая высокоуровневый код, как ты отличишь обращения к свойству от прямого обращения к полю?

Добавлено 29.10.11, 14:42

Цитата Romkin @ 29.10.11, 12:56

Свойства улучшают читабельность.

Каким образом?

Добавлено 29.10.11, 14:44

Цитата Qraizer @ 29.10.11, 08:05

Romkin, если у тебя окажется ромб в интерфейсах

А к каким проблемам приводит робм в интерфейсах?

[Flex Ferrum]

Цитата D_KEY @ 29.10.11, 14:34

Может. С помощью соответствующих методов. Зачем на это нужно наворачивать еще нечто, уменьшающее прозрачность?

А чем это будет принципиально отличаться от доступа к свойству, как к атрибуту? Основная идея инкапсуляции в чём? Внешние клиенты могут менять состояние объекта только разрешённым и контролируемым способом, описываемом в публичном интерфейсе. Если обращение к атрибуту явным образом контролируется объектом, то в чём проблема?

Цитата D_KEY @ 29.10.11, 14:34

Читая высокоуровневый код, как ты отличишь обращения к свойству от прямого обращения к полю?

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

[Qraizer]

Цитата Romkin @ 29.10.11, 08:22

Каким образом окажется ромб в интерфейсах? Это принципиально невозможно, у интерфейса нет полей данных и виртуальных методов.

И что? Если у нескольких интерфейсов общий предок, их реализации не могут столкнуться с одинаковыми аттрибутами? Откуда принципиальная невозможность-то?

Добавлено 29.10.11, 18:08
В общем, я понял. Мой вопрос имеет ответом сам себя, только без ? в конце. Рассматриваю это как ещё один гвоздь.
Вопрос вообще-то был навеян обсуждением пропертей.

Добавлено 29.10.11, 18:20

Цитата D_KEY @ 29.10.11, 14:34

А к каким проблемам приводит робм в интерфейсах?

Ни к каким.
Проблем множественного наследования реализаций не существует. Существует задача дизайна системы, иногда сводящаяся к множественным базовым классам, и решаться эта задача должна архитектором системы. Это он должен определить, какие аттрибуты совмещаются, какие разделяются, и каким именно способом, модет быть даже определяя инварианты для них. Когда задача решена, программист реализует её в коде, пользуясь предоставленным инструментарием выбранного языка. В Дельфи я вижу неплохой инструмент для архитектора, но ущербный для программиста.

Сообщение отредактировано: Qraizer - 29.10.11, 18:21

[D_KEY]

Цитата Flex Ferrum @ 29.10.11, 15:35

Если обращение к атрибуту явным образом контролируется объектом, то в чём проблема?

Проблема в том, что есть еще один уровень непонятного назначения(ну максимум - синтаксический сахар), который влияет на проектирование(как показал korvin).

Добавлено 29.10.11, 19:04

Цитата Qraizer @ 29.10.11, 18:06

Ни к каким.

Тогда я не понял, в чем заключался твой вопрос.

Цитата

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

Во-первых, в С++ тебе нужно определиться с виртуальностью базового класса не тогда, когда у тебя появился ромб, а при создании "среднего" класса, что печально. В данном случае реализация повлияла на языковую концепцию... В том же Eiffel эта проблема решается иначе, причем один атрибут верхушки ромба у тебя может быть "виртуальным", а другие нет. И определяет это программист того класса, в котором ромб возник.
Во-вторых, я не очень понимаю, как это связанно с интерфейсами, ведь в них этих вопросов не возникает, даже при ромбе.

Сообщение отредактировано: D_KEY - 29.10.11, 19:05

[korvin]

Цитата Romkin @ 29.10.11, 12:56

Доступ к приватному полю через метод - это прямой доступ?

доступ к сеттеру/геттеру через свойство -- это прямой доступ к сеттеру и геттеру (прямой вызов сеттера и геттера), т.о. свойство ничего не скрывает

Цитата Romkin @ 29.10.11, 12:56

Может быть и я не понял твой код. Я не понимаю, как можно связать разнородные объект, не написав под каждый тип свой вспомогательный объект.

эээ... у меня нет никаких вспомогательных объектов, у меня есть объект Memo, в который заносятся данные и объект anyObject, из которого беруться данные и который реализует интерфейс CanGiveCollection<Stringable>, поэтому не понимаю о каком вспомогательном объекте идет речь.

Цитата Romkin @ 29.10.11, 12:56

Свойства улучшают читабельность. Сам же запутался, получаем length, а устанавливаем через resize. Да, никаких заблуждений.

я? не запутался, в чем путаница? и почему мы не можем изменять length с помощью resize? тебе не знакомы значение/перевод этих слов?

[Qraizer]

Цитата D_KEY @ 29.10.11, 18:58

Тогда я не понял, в чем заключался твой вопрос.

А как проблемы множественного наследования относятся к моему вопросу? Вопрос был о потенциальной возможности управлять делением/совмещением отдельных атрибутов множественной базы без ручного кода. Библиотечный за ручной не считается, если он писан один раз и навсегда.

Цитата D_KEY @ 29.10.11, 18:58

Во-первых, ...

Я не говорил, что в Плюсах с этим гладко. И если ты помнишь, когда шёл разговор о множественном наследовании реализаций, не пытался доказывать обратное. Опять же, вопрос не в этом.

Цитата D_KEY @ 29.10.11, 18:58

Во-вторых, ...

Может возникнуть при реализации. Особенно, если они попытаются заагрегировать уже готовые. (Хотя истинные труъ безусловно пойдут перепроектировать, не дай бог кто увидит.) К примеру реализация базовых потоковых IO операций должна быть едина для потоков ввода/вывода, следовательно атрибут, например, состояния потока - всякие там good, fail etc - должен совмещаться. Так <iostream> и поступает. А реализации IUnknown обязаны быть разделены, чтобы у каждого были свои счётчики. Или счётчик пользователей не является аттрибутом, потому что непубличный?

[Flex Ferrum]

Цитата D_KEY @ 29.10.11, 18:58

Проблема в том, что есть еще один уровень непонятного назначения(ну максимум - синтаксический сахар), который влияет на проектирование(как показал korvin).

Да. Он влияет на проектирование. Делает интерфейс класса более очевидным и приближенным к реальности.

[korvin]

Цитата Flex Ferrum @ 30.10.11, 06:53

Делает интерфейс класса более очевидным и приближенным к реальности.

нет, он привносит дополнительную ненужную сущность и вводит в заблуждение, что усложняет проектирование и ухудшает восприятие кода, делает синтаксис менее строгим и очевидным, что тоже ухудшает восприятие кода

[Flex Ferrum]

Цитата korvin @ 30.10.11, 08:23

нет, он привносит дополнительную ненужную сущность и вводит в заблуждение, что усложняет проектирование и ухудшает восприятие кода, делает синтаксис менее строгим и очевидным, что тоже ухудшает восприятие кода

Да что ты? Всё-таки я не понимаю, почему запись вида "int size = object.size;" хуже записи вида "int size = object.size()" или "int size = object.getSize();". На счёт сеттеров - тоже всё не так просто. С установлением новой длины - понятно. resize(int newLen) будет выглядеть логичнее. Но есть и другие случаи. Например, r/w-свойство Caption, отображаемое на заголовок окна. Чем запись "window->setNewCaption("Something New")" лучше, чем "window->Caption = "Something New";"?

[korvin]

Цитата Flex Ferrum @ 30.10.11, 08:40

Да что ты? Всё-таки я не понимаю, почему запись вида "int size = object.size;" хуже записи вида "int size = object.size()" или "int size = object.getSize();".

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

Добавлено 30.10.11, 09:08

Цитата Flex Ferrum @ 30.10.11, 08:40

Чем запись "window->setNewCaption("Something New")" лучше, чем "window->Caption = "Something New";"?

эта? ничем, а, например,

window.changeCaptionTo "New Caption"

лучше их обеих