Ответ на »сообщение 2740« (Trurl)
___________________________
>>>Записи Оберона соответстсвуют скорее записям, а не объектам Дельфи.
Однако с их помощью реализуется объектный подход. Сторонники Оберона утверждают, что это делается просто и естественно. Скептики считают, что слишком много общих механизмов приходится реализовывать повторно.
В данном случае я со скептиками: конструкторы - весьма удобный и полезный инструмент.

Ответ на »сообщение 2739« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2738« (AVC)
___________________________
И кстати это тоже показывает ограниченность ОО как инструмента.

Да, ОО в распространившемся понимании ограничено и часто приводит к большим проблемам в развитии систем. Именно поэтому полезен выход за "мейнстримовские" нормы реализации ООП, потому что это принуждает мыслить по-другому и грамотно строить систему. Нет конструкторов - программист просто ОБЯЗАН, обязан всей идеологией, всеми нормами, всеми примерами, которые видит, использовать гомогенные иерархии с четким выделением абстрактных интерфейсов и объектами-фабриками (в ББ называемыми "каталогами"). И сам же потом говорит за это спасибо, потому что получает расширяемую, гибкую систему, с четким разбиением на интерфейсы и реализацию, лего разделяемую на подсистемы, взаимодействующие через "узкие горла".

А в плане средств статического контроля правильности ООП - ни в одном языке они так не продуманы, как в Компонентном Паскале - для того и пачка модификаторов ABSTRACT, EXTENSIBLE, LIMITED, NEW...

Ответ на »сообщение 2737« (AVC)
___________________________
>>>Как насчет единицы инкапсуляции (разделение интерфейса и реализации)?
>>>Вообще, формулу класс = тип + модуль не я придумал (а Б.Мейер).
Не важно, кто придумал, цитируете - отвечайте :)
Насчет единицы инкапсуляции боюсь опять увязнем в терминологии.
Точное определение инкапсуляции приведете?
Record под него не попадет?

Ответ на »сообщение 2736« (Jack Of Shadows)
___________________________
>>>ТО есть каждый раз создавать тот самый механизм от которого отказались :))
Ровно это я и пытался сказать, видимо не очень четко :)

Ответ на »сообщение 2751« (AVC)
___________________________
Наследование реализации полезно и используется в "каркасе", т.е. когда разработчику предоставляются заготовки с некоторым поведением, которые он достраивает под себя. В ББ такими заготовками являются базовые графические типы - Views.View, Containers.Container, Controls.Control. Однако заготовки, хотя и имеют некоторые конкретные реализованные процедуры, объявляются как ABSTRACT, и создать их экземпляр невозможно.

Ответ на »сообщение 2742« (Антон Григорьев)
___________________________

И прошу не оставлять без внимания такой вопрос (его уже озвучил Jack of Shadows): можно ли в Обероне создать такой тип, что его экземпляры можно будет создавать только через фабрику, но при этом другие модули не потеряют возможности создавать расширения этого типа?

В КП существует два способа обязать клиентов создавать объекты только через фабрику: (1) LIMITED типы, (2) ABSTRACT типы + скрытая конкретная реализация.
Ни в одном из этих случаев клиент не может сам расширить конкретные типы. Для того, собственно, и созданы LIMITED типы и скрытые реализации.
Я хочу подчеркнуть, что это сделано специально.
Ведь Оберон создавался с прицелом на расширяющее и компонентное программирование, а наследование реализации не слишком с этим сочетается (проблема хрупких классов и т.п.).

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

Ответ на »сообщение 2742« (Антон Григорьев)
___________________________

Ответ на »сообщение 2734« (AVC)
___________________________
Почему ж не способен? От реализации зависит. В Delphi, например, конструкторы могут быть виртуальными, и на этой особенности вся библиотека VCL построена.
Кстати, хотелось бы увидеть пример, как фабрика может заменить виртуальный конструктор вот в таком случае:
Есть модуль A. В нём объявлен тип A.B. И в этом же модуле есть некоторая процедура A.X, которая для своих внутренних нужд может создать экземпляр любого типа, являющегося расширением A.B. Какого именно типа - это передаётся процедуре A.X извне через её параметры. Модули, в которых определяются расширения типа A.B, а также осуществляются вызовы A.X, на момент компиляции модуля A ещё не существуют. В Delphi через виртуальные конструкторы и указатели на классы это делается элементарно. А в Обероне?

Все делается точно также, только используется не процедура-фабрика, а объект-фабрика. Вместо "указателя на класс" процедуре передается указатель на фабрику.

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

Ответ на »сообщение 2742« (Антон Григорьев)
___________________________

Почему ж не способен? От реализации зависит. В Delphi, например, конструкторы могут быть виртуальными, и на этой особенности вся библиотека VCL построена.

Антон, не могли бы Вы сказать пару слов о реализации виртуальных конструкторов в Дельфи?
Я перестал использовать Object Pascal до появления в нем виртуальных конструкторов и динамических методов, поэтому, к сожалению, не в курсе.
Когда я говорю о конструкторе, то ориентируюсь прежде всего на Си++, где конструктор жестко привязан к конкретному классу. "Виртуальный конструктор" (в моем понимании) -- способ создавать объект, класс которого заранее не известен (а иногда даже специально скрыт).

в дополнение на »сообщение 2747« ()
___________________________
Вы неправы и правы оба одновременно.
Другими словами - само проведение подобных "контрольных замеров" в ОС с названием "Windows*" совершенно лишено всякого смысла... Либо вы будете получать "в среднем по палате"...

Ответ на »сообщение 2745« (info21)
___________________________
Обязательная проверка границ массива снижает быстродействие программы в среднем на 5%.
Неправда. В мало-мальски реалистичных случаях это скорее 1-2%, когда вообще удается измерить.
Вы неправы и правы оба одновременно.
И 5%, и ваши 1-2% - просто результат каличности винды, в которой механизмы параллельности писались или в сильнейшем пьяном угаре, или студентом-недоучкой. Вы просто в переделах "погрешности" оба.