Ответ на »сообщение 2763« (Сергей Перовский)
___________________________

А для РАЗРАБОТКИ объектов невозможность использовать прототипы - большой минус.

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

Для чего задумывался класс? Для инкапсуляции (данные + поведение) -- что по Хоару (record class), что по Далу-Нигаарду. Инкапсуляции прозрачной, не предусматривающей information hiding. Потом начался центростремительный процесс создания однополярного мира под названием ООП. Есть класс, все остальное -- ерунда. В него запихнем все что можно, потом будем разгребать эту кучу...

Класс вроде бы исходил из классификации иерархической, которой дали название наследование (inheritance). Ну наследование, так наследование. Но потом так завязли в ООП, что стали думать как справиться при этом однополярном мире со все новыми и новыми проблемами, которые сам мир и создал: множественное наследование, композиция, агрегация, делегирование...

Это и есть, с моей точки зрения, чисто операционный подход (не важно зачем, важно как; khow how), в противовес концептуальному (know why). Вы не обратили внимание, что сейчас программирование как деятельность сводится преимущественно к программированию на конкретном языке? Оно к нему прилипло намертво. Мы обсуждаем все больше технические проблемы того или иного языка или (как в случае данной дискуссии), как средства одного языка воплотить в другом. Может, не от того танцуeм? Может, прежде чем строить, думать надо?

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

Можно тонны литературы по проектированию написать (правильному!)... Но пока средства языка позволяют делать вот так:
...

#define private public
#define protected public

#include "need_class_file.hpp"

#undef private
#undef protected
...
юзаем "кишки" предков по полной программе (а коллеги удивляются разным "эхвектам". ... ну, или их отсутствию :) )...

... мы будем только сокрушаться, о том какие идиоты иногда садятся за комп...

ЗЫ Между прочим, у человека, что это написал, крепкий здоровый сон...

Ответ на »сообщение 2763« (Сергей Перовский)
___________________________
для РАЗРАБОТКИ объектов невозможность использовать прототипы - большой минус.
А что вы понимаете под прототипами? Реализацию заявленной функциональности интерфейса? Но при сегодняшнем понимании объектов, вы вынуждены будете открывать класс. Потому, что у вас не описывается формализованным образом семантика обмена по вызовам.

Ответ на »сообщение 2761« (Руслан Богатырев)
___________________________
>>>По мысли Алана Кея, каждый объект должен быть подобен маленькому компьютеру, который совмещает в себя данные и "программы" (методы). При такой модели для взаимодействия объектов между собой нет надобности открывать реализацию.
С точки зрения специалиста по сетям, компьютер может быть опломбирован :)
А с точки зрения производства компьютеров, начинать каждый компьютер проектировать начиная со спецификаций - абсурд.
Для ВЗАИМОДЕЙСТВИЯ объектов между собой нет надобности открывать реализацию в любом варианте.
А для РАЗРАБОТКИ объектов невозможность использовать прототипы - большой минус.

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

Так что когда речь идёт про ООП, Оберон для меня по-прежнему не выглядит надёжным языком.

А что Вы понимаете под надежностью? И что -- под надежным языком? Вопрос не праздный.

Ответ на »сообщение 2759« (Сергей Перовский)
___________________________

А при неграмотном и в Обероне можно такого наворотить :)

Верно. Наворотить можно в любом языке. Только наворот навороту рознь.


Насчет единицы инкапсуляции боюсь опять увязнем в терминологии.
Точное определение инкапсуляции приведете?
Record под него не попадет?

Вообще-то лучше следовать классике. Дэвид Парнас в работе "On the Criteria To Be Used in Decomposing Systems into Modules" ввел понятие information hiding (информационное сокрытие). Термин "инкапсуляция" он не использовал.

А вот инкапсуляция (encapsulation) -- это связывание данных с операциями по их обработке (с методами в ООП). Связанные процедуры Oberon-2 и КП -- это инкапсуляция, а управление информационным сокрытием передано модулю. При этом модуль можно рассматривать и как средство "слабой инкапсуляции", например, при реализации абстрактных типов данных (без ООП), когда тип (абстрактный) и операции по работе с ним вложены в "коробочку" под именем "модуль". Набор методов (поведение) должно быть неотъемлемо от объекта, это азбука ООП в истоках Симулы (Дала и Нигаарда).

По мысли Алана Кея, каждый объект должен быть подобен маленькому компьютеру, который совмещает в себя данные и "программы" (методы). При такой модели для взаимодействия объектов между собой нет надобности открывать реализацию.

С ООП ситуация вообще интересна: идеи заложил один (Тони Хоар), первую модель воплотили другие (Дал и Нигаард), "эталонную" модель и термин "object-oriented" -- следующий (Алан Кей), а богатую почву для последующих "лесов" интерпретации еще один (Бьерн Страуструп). В результате никто сейчас не может дать дать спецификацию ООП, которая была признана эталоном. На это даже замахнулся Бертран Мейер, получивший за свой труд "Object-Oriented Software Construction" в 2005 г. премию Дала-Нигаарда. Но его книгу просто приняли к сведению... Да и на эталон по ООП она как-то не тянет...

Ответ на »сообщение 2755« (Илья Ермаков)
___________________________

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

Чем ваша фраза отличается от такой?

Нет проверки границ массива - программист просто ОБЯЗАН, обязан всей идеологией, всеми нормами, всеми примерами, которые видит, проверять их самомстоятельно.

Может ли использование оператора goto, приведение типов, арифметика указателей давать хороший код? Могут. А могут и не давать - всё зависит от кривизны рук использующего. Из Оберона эти средства удалены, и хорошо. Но средства ООП, вообще говоря, отсутствуют (особенно в оригинальном Обероне). И это, кстати, неудивительно - Вирт и не скрывает, что ООП он считает просто коммерческим трюком (цитирую по памяти его выступление в Москве: "Они называют тип классом, переменную - объектом, процедуру - методом, и говорят, что это - новая концепция программирования"). Поэтому ООП в Обероне приходится имитировать относительно низкоуровневыми средствами, и средства эти можно использовать правильно, а можно - неправильно. Так что когда речь идёт про ООП, Оберон для меня по-прежнему не выглядит надёжным языком.

Ответ на »сообщение 2751« (AVC)
___________________________
>>>Ведь Оберон создавался с прицелом на расширяющее и компонентное программирование, а наследование реализации не слишком с этим сочетается (проблема хрупких классов и т.п.).
Не могу удержаться, чтобы не ответить любимой на этом форуме фразой:
ПРИ ГРАМОТНОМ ПРОЕКТИРОВАНИИ проблема хрупких классов не возникает.
А при неграмотном и в Обероне можно такого наворотить :)

Ответ на »сообщение 2754« (Сергей Перовский)
___________________________

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

Формула "класс = тип + модуль", в частности, воплощена в С++, где инкапсулирующей единицей является класс, где класс может содержать внутри себя любую иерархию объявлений вложенных подклассов и т.п. Мейер в Ейфеле пошел тем же путем. "Смешались в кучу кони, люди...", в общем.
Класс одновременно и тип данных, и модуль - чтобы принять такое определение, да еще правильно использовать классы в двух ипостасях, нужно порядком вывихнуть мозговые извилины :-)

Ответ на »сообщение 2749« (AVC)
___________________________

Антон, не могли бы Вы сказать пару слов о реализации виртуальных конструкторов в Дельфи?

С точки зрения исходного кода виртуальный конструктор выглядит так же, как и любой другой виртуальный метод. Чтобы конструктор стал виртуальным, его надо объявить со словом virtual, в потомках перекрывать со словом override. С виртуальными конструкторами тесно связаны указатели на классы (в других языках аналогичные типы называют метаклассами). Если тип TSample является классом, то можно объявить такой тип:

TSampleClass = class of TSample;

Пусть TSample1 и TSample2 - наследники TSample (может быть, не непосредственные), а SampleClass - переменная типа TSampleClass. Тогда допустимы следующие присваивания:

SampleClass:=TSample;
SampleClass:=TSample1;
SampleClass:=TSample2;

Если Sample имеет тип TSample, допустимо такое создание нового объекта:

Sample:=SampleClass.Create;

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