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

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

Проект единой библиотеки пока, скажем так, на новогодних каникулах.
Надеюсь, в ближайшее время работа возобновится.

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

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

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

Пусть будет кризис... углубляться не будем... Хорошо?
Да я и не хотел. Просто в следующий раз, когда будете убеждать кого-то в чём-то, пытайтесь хотя бы отдалённо следовать своим же поучениям. А то как-то некрасиво получается...

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

Ответ на »сообщение 4286« (hugi)
___________________________
Сложные... говорите... Я приводил ссылку на разработанную нами систему. Вы относите ее к простым? ERP+MES+CRM+SCM+... Хм...
...и...
... ничего более :)

Вы уверены, что знаете «мой подход» настолько хорошо, чтобы делать выводы? Удивительно... Тот факт, что трудоемкость разработки была снижена на два порядка... свидетельствует о том, что мой подход «преумножает сложность»?..

Тогда, могу предположить, используя сведения о Вашем подходе, описанном в сообщениях, адресованных мне, что вся ваша система описана в одном классе, который является "агрегатом ролей" (это по аналогии с Вашим HomoSapiens). Но мне почему-то кажется, что Вы, вопреки своим рассуждениям, сделали иначе
Не давал я таких сведений... да, и... Homo такой же мой, как и Ваш... :)

Не хотелось бы мне цитировать Г. Буча, но если будете настаивать...
Ну, если Вы брезгуете, придётся мне. Сразу извиняюсь за большой объём цитаты.
Не брезгую, но лень-матушка... В электронном виде не имею, а перенабивать тексты... скучно.

На рис. 4-1 показаны 10 поездов, обозначенных буквами от А до J. Каждое изображение состоит из паровоза и нескольких вагонов. Прежде чем продолжать чтение, попытайтесь за 10 минут определить несколько групп изображений, составленных по какому-то логическому признаку. Например, изображения можно разбить на три группы: в одной группе поезда имеют черные колеса, в другой группе - белые, а в третьей - и белые, и черные.
Где тут про наследование?
Нет... ничего нет про наследование, Вы правы... Но открываем раздел «Наследование и типизация»:
Тем самым мы подходим к фундаментальным вопросам наследования. Как сказано выше, наследование используется в связи с тем, что у объектов есть что-то общее или между ними есть смысловая ассоциация (стр. 126)
Соотнесите свою цитату и мою...

P.S.
И ещё, что это Вы вдруг стали на авторитеты ссылаться: Будда сказал, Лао-Цзы сказал... У Вас что, кризис мировоззрения?
Пусть будет кризис... углубляться не будем... Хорошо?

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

Считаете ли Вы Администратора разновидностью Гостя?
Мне так не кажется, поэтому Ваше "т.е." кажется мне "натяжкой".
Я считаю, что Администратор (равно как и Гость) -- разновидность пользователей системы, причём Администратор обладает большей по сравнению с Гостем функциональностью (включая в её состав возможности Гостя). Не использовать для этого наследование я считаю не очень разумным шагом.

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

Сложные... говорите... Я приводил ссылку на разработанную нами систему. Вы относите ее к простым? ERP+MES+CRM+SCM+... Хм...

...и...

Вы уверены, что знаете «мой подход» настолько хорошо, чтобы делать выводы? Удивительно... Тот факт, что трудоемкость разработки была снижена на два порядка... свидетельствует о том, что мой подход «преумножает сложность»?..

Тогда, могу предположить, используя сведения о Вашем подходе, описанном в сообщениях, адресованных мне, что вся ваша система описана в одном классе, который является "агрегатом ролей" (это по аналогии с Вашим HomoSapiens). Но мне почему-то кажется, что Вы, вопреки своим рассуждениям, сделали иначе.

Не хотелось бы мне цитировать Г. Буча, но если будете настаивать...
Ну, если Вы брезгуете, придётся мне. Сразу извиняюсь за большой объём цитаты.

Проблема классификации

На рис. 4-1 показаны 10 поездов, обозначенных буквами от А до J. Каждое изображение состоит из паровоза и нескольких вагонов. Прежде чем продолжать чтение, попытайтесь за 10 минут определить несколько групп изображений, составленных по какому-то логическому признаку. Например, изображения можно разбить на три группы: в одной группе поезда имеют черные колеса, в другой группе - белые, а в третьей - и белые, и черные.

Этот пример взят из работы Степпа и Михальски о концептуальном объединении [19]. Очевидно, "правильного" разбиения на группы не существует. Наши изображения были классифицированы 93 различными способами. Наиболее распространенный способ классификаций по длине состава: были выделены три группы: составы с двумя, тремя и четырьмя вагонами. Второй по популярности вид классификации - по цвету колес поезда. Сорок из девяносто трех видов классификации были уникальными (то есть вид содержал только один экземпляр).

Экспериментируя с этим рисунком, мы убедились в правоте Степпа и Михальски. Большинство опрошенных нами предлагали один из двух наиболее популярных видов классификации (по длине состава и цвету колес поезда). Один опрошенный предложил следующее: в одной группе составы помечены буквами, нарисованными с помощью только прямых линий (A, Е, F, H и I), в другой - буквами с кривыми линиями. Вот уж, действительно, пример нетривиального мышления.

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

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

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

P.S.
И ещё, что это Вы вдруг стали на авторитеты ссылаться: Будда сказал, Лао-Цзы сказал... У Вас что, кризис мировоззрения?

Ответ на »сообщение 4267« (info21)
___________________________
Наследование (в ООП) – всегда классификация ...
Конкретно в Блэкбоксе: дан базовый тип View. От него производятся разные, никак между собой не связанные конкретные вьюшки.
Никакого отношения к классификации это не имеет, если не считать классификацией любое определение -- что малоинтересно, ибо в таком вырожденном случае понятие классификации лишнее.
(ЗЫ Какое однако любопытное упорное увязывание наследования и классификации... надо полагать, свидетельство силы импринтинга в юном возрасте.)
Подклассы не должны быть между собой связаны, но они должны наследовать от суперкласса его «структуру и поведение»... Если наследование имеет место быть, то любой объект подкласса относится и к суперклассу, то есть, в той же мере является и экземпляром суперкласса. Разнесение же сущностей к классам и есть классификация.
В Вашем примере, если от базового типа View наследованы вьюшки, то зачем-то это было сделано... Или, говоря иначе, что-то общее из всех вьюшек было вынесено во View, так чтобы не «размазывать» это общее (родовые свойства) по реализациям подклассов.

Ответ на »сообщение 4280« (Горбунов-Посадов)
___________________________
Какую связь между "базой данных" реестра и ООП Вы имеете в виду?
Реестр и БД – это информационные хранилища. Но механизмы любой приличной СУБД более развиты... и стандартизованы.

Я слышал только об одной базе данных, изредка упоминаемой в контексте программистского инструментария, — о базе данных проекта. Нельзя сказать, что ООП ее полностью игнорирует, но, в то же время, она, кажется, не входит в число опорных понятий ООП. Если Вы что-либо знаете о реализованных инструментах взаимодействия базы данных проекта, использованной при построении приложения, и реестра Windows, буду Вам весьма признателен за такую информацию
Нет, про реестр Windows, я ничего (хорошего) сказать не могу...

Или я что-то не так понял в Вашем замечании? Возможно, Вы имели в виду, что энергичное использование универсальных механизмов СУБД при подключении к программе нового компонента — вполне обыденное дело для ООП? Это было бы очень неплохо, но не думаю, что такое расширенное толкование ООП общепринято
Дело не общепринятости... Есть такое понятие, как «объектная фабрика» (его тоже не стоит причислять к общепринятым понятиям). По сути ОФ должна обслуживать множество программ, создавая/восстанавливая/сохраняя/разделяя для них объекты. При этом могут создаваться новые классы, которые тут же могут использоваться работающими программами. Это похоже на совместную работу пользователей с БД (один завел информацию, другие ее увидели и как-то обработали). Можно найти/увидеть (провести) много параллелей между СУБД и ОФ. Это первое, о чем я хотел сказать.
Второе. Технология создания СУБД и ОФ так же может быть «объектной». С десяток лет назад я описывал наш проект по разработке СУБД (сам проект выполнялся в начале 90-х). В этом проекте использовались те объектные технологии, о которых я сейчас пытаюсь рассказать. Это не то, что общепринято, но интересно... по-своему.

Ответ на »сообщение 4277« (Горбунов-Посадов)
___________________________


Зато, IMHO, здесь полная параллель с каркасом.
Лексическая и синтаксическая составляющая -- каркас, а генерация кода -- специфическая часть (для каждого нового процессора).
Конечно. Равно как и каркас из пары "синтаксический анализ -- генерация кода" при локализации языка или каркас "лексический анализатор -- генератор кода" при реализации различных синтаксических вариаций для семантически одних и тех же языковых констркуций (типа наличие-отсутствие fi в условном операторе). Главное -- в предметной области были вычленены относительно самостоятельные компоненты (модули, инварианты? в данном случе -- три фазы компиляции), после этого любая их комбинация может, в зависимости от ситуации, оказаться и в каркасе, и вне его.

Да, действительно, можно также создать несколько front end-ов для одного back end-а (генератора кода).
Я почему-то о такой возможности сначала не подумал, хотя она очевидна.
И здесь могут быть свои тонкости.
Например, в разных языках даже самые простые операции могут иметь разные определения.
Достаточно указать на разное определение целочисленного деления и взятия остатка в языках Оберон и Си.
В Обероне целочисленное деление понимается так:
x DIV y = ENTIER(x/y). (ENTIER = наибольшее целое <= x/y, похоже на floor(x/y) в Си, но имеет  целочисленный тип.)
Поэтому, например, (-5) DIV 2 = -3, а не -2, как в Си.

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

Ответ на »сообщение 4281« (Сергей Губанов)
___________________________

Но Stores, как и Views -- не компоненты.
Компоненты -- подсистемы Text, Form и т.д. К этим последним никаких претензий быть не может: реализацию можно подменить at run time, подменив соотв. фабричный объект (SetDir).