Ответ на »сообщение 4220« (AVC)
___________________________
КОП = ООП + модульность + безопасность - наследование (через границы модулей).
Утверждалось, что в компонентно-ориентированном программировании (КОП) через границы модулей наследовать можно только абстрактным, интерфейсным типам.
IMHO, ясно, что при таком подходе наследование (за исключением наследования интерфейса) не может рассматриваться как основной программистский инструмент. Предпочтение отдается композиции
Хм... композиция лежит в основе агрегации, классификация лежит в основе наследования... Как можно предпочесть соленое круглому?
Если уж... совсем погрузиться в... то агрегация – это количественное, а наследование – качественное изменения предмета (или предметной области)...

Насколько я понимаю, спор идет о "наследовании". :)
Т.к. этот спор идет на обероновском форуме, то имеет смысл вспомнить утверждение, приводившееся на сайте "Информатика-21":

КОП = ООП + модульность + безопасность - наследование (через границы модулей).

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

Я не утверждаю, что это единственно правильная точка зрения; это просто информация к размышлению.

Еще тут обсуждается вопрос о возможности создать "правильную" модель (например, склада).
Вот взгляд с совершенно другой, "не обероновской", стороны -- интересная статья С.Меллора (одного из авторов известного метода объектно-ориентированного анализа) об управлении меняющимися требованиями к ПО: "Managing changing requirements".

http://www.embedded.com/story/OEG20010725S0103

Здесь он говорит о выделении инварианта и помещении всех потенциально меняющихся компонентов задачи в данные.
(Отмечу, что здесь другой подход: создается модель, которая затем транслируется в код.)

Ответ на »сообщение 4215« (Горбунов-Посадов)
___________________________
Однако представляю себе и позицию Вашего оппонента-учетчика, который заявит (в полном соответствии с тем, что Вы только что сказали), что понятие учет (и, соответственно, реализованный оппонентом класс "Учет") — масштабнее: оно успешно отражает, в частности, и нередко встречающуюся возможность работы "с колес", а следовательно, уж если кого и ставить в подчиненное положение, то именно "демпфер". И спор этот бесперспективен, а навязан, как мне все же кажется, именно тенденцией ООП к насаждению иерархии там, где ее нет
Учет не может быть «масштабнее» склада. Учет – это функция (как функциями являются и анализ, и регулирование...), а склад (демпфер) – это сущность. Само сравнение неправомерно и ни о каком споре говорить не имеет смысла.
Выдумывать иерархии (под задачу) пустая трата времени, но использовать естественные иерархии очень желательно. Не стоит безоглядно следовать канонам... но понимание логики развития сущностей предметной области позволяет получать очень простые и эффективные решения. Собственно, это я и хотел продемонстрировать примером со складом. То же самое можно показать и на других предметных областях.
Поэтому я согласен с Вами в том, что от «насаждения иерархий» мало пользы, но от правильного использования наследования польза очень велика.

Натуральные модули.

В противовес всем остальным искусственным модулям.

Ответ на »сообщение 4190« (Trurl)
А может быть лучше Вам подкорректировать название для своих модулей?
Натуральные модули.

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

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

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

Если можно, здесь поподробнее, пожалуйста.

Процитирую три примера, которые здесь уже приводились (сообщение 3950 и др.), и добавлю к ним четвертый.

1. Добавление модуля рисования эллипса к графическому редактору. В меню это добавление должно привести к появлению нескольких пунктов: эллипс, окружность (наиболее интересный частный случай) и др. Помимо текстового меню, вероятно, добавление эллипса повлечет появление иконки эллипса в меню графическом. А также, например, небольшого сопутствующего раздела в справке. И т.д., и т.п. Кроме того, хотелось, чтобы разочаровавшись в эллипсе, разработчик мог бы одним щелчком выбросить его из своего графического редактора со всей сопутствующей атрибутикой: и из основного объектного кода, и из всех меню, и из справки.

2. Как правило, появление в сложившейся структуре нового нетривиального компонента (модуля) должно сопровождаться пополнением нескольких расширяемых наборов. Например, вы оформились на работу в некоторое учреждение. При этом ваша фамилия должна появиться в телефонном справочнике, ваше фото -- на доске "Наши лауреаты Нобелевской премии", а ваши правнуки должны пополнить список претендентов на новогодние подарки. И обратно, при вашем увольнении одновременно стирается строчка в справочнике, снимается фото с доски и забывают о ваших потомках.

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

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

Во всех этих историях идет речь о горизонтальных связях в программе. Тут можно позволить себе несколько кощунственное с точки зрения традиционного модульного программирования утверждение: чем больше такого рода горизонтальных связей имеет подключаемый модуль расширения — тем лучше. Именно горизонтальные связи превращают сообщество модулей в слаженный коллектив единомышленников, создают благоприятную, благожелательную среду для подключения нового модуля.

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

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

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

Попробуем продолжить рассуждать. Склада, который не демпфирует материальные потоки, быть не может (он просто не будет иметь смысла), но склад, который не ведет учета, может существовать (например, тривиальная автоматическая камера хранения, где никто не заявляет то, что сдает). С другой стороны, учет материальных потоков существует вне склада (например, при работе «с колес» учет есть, а склада нет). То есть, учет это некая «функция», которую, в том числе, может выполнять и склад.
Что же это за учетная функция? Здесь все просто... Помните из теории систем, «систему с обратной связью»? Что из себя представляет обратная связь? На выходе из исполнительного устройства (ИУ) стоят датчики (Д), которые снимают показатели выходного потока и передают их на анализатор (А). Помните? Так вот, учет представляет собой один из каналов обратной связи... Иными словами, если мы захотим рассматривать склад, как систему с обратной связью, то мы должны будем, в том числе, организовать и учет на складе. (На всякий случай замечу, что обратная связь нужна далеко не всегда!).
Из сказанного выше следует, что понимая учет, как вариант обратной связи, можно добавить его [учет] или ее [обратную связь] к существующей реализации «склада-демпфера», не внося изменений (только дополнения!) в то, что уже сделано.

Если вести речь о строгом определении понятия "склад", готов с Вами согласиться и поставить "склад-учет" в подчиненное положение, "добавив его к существующей реализации" (по-видимому, Вы имели в виду демпфер-реализацию класса "Склад"). Однако представляю себе и позицию Вашего оппонента-учетчика, который заявит (в полном соответствии с тем, что Вы только что сказали), что понятие учет (и, соответственно, реализованный оппонентом класс "Учет") — масштабнее: оно успешно отражает, в частности, и нередко встречающуюся возможность работы "с колес", а следовательно, уж если кого и ставить в подчиненное положение, то именно "демпфер". И спор этот бесперспективен, а навязан, как мне все же кажется, именно тенденцией ООП к насаждению иерархии там, где ее нет.

С Новым Годом Вас и всех, кто, возможно, нас читает!

Ответ на »сообщение 4213« (Alexander Shiryaev)
___________________________

Есть ли в BlueBottle что-нибудь аналогичное Stores в BlackBox ?

Ответ на »сообщение 4212« (Alexander Shiryaev)
___________________________

Почему-то убралась табуляция :-(

Всех с Новым Годом !


Помогите составить алгоритм для BlueBottle.
Есть N (~10^4-10^6) активных объектов. У каждого объекта через случайный период времени из заданного диапазона должна запускаться процедура (Activate). При загрузке модуля должны запускаться все N объектов, при выгрузке - останавливаться.

Вот что у меня примерно получилось сделать, но надо сделать проще. И ещё почему-то иногда появляются TRAP-ы

MODULE AixDoorways;

IMPORT
AosKernel, AosOut, AosRandom, AosModules;

CONST
N = 10000;

TYPE
RGen = OBJECT (* генератор случайных таймаутов для объектов *)
VAR gen: AosRandom.Generator;

PROCEDURE & Init;
BEGIN
NEW(gen);
END Init;

PROCEDURE Timeout ():LONGINT;
BEGIN {EXCLUSIVE}
RETURN gen.Dice(30000) + 10000
END Timeout;

END RGen;

A = OBJECT
VAR id: INTEGER; (* object identifier *)
state: SHORTINT; (* object state: 0 - not created, 1 - stopped, 2 - started, 3 - terminate, 4 - terminated *)
time: AosKernel.Timer;
activations: INTEGER;

PROCEDURE & Init (id: INTEGER);
BEGIN
SELF.id := id;
state := 0;
NEW(time);
activations := 0
END Init;

PROCEDURE Create;
BEGIN {EXCLUSIVE}
ASSERT(state = 0);
(* ...some code... *)
state := 1
END Create;

PROCEDURE Start;
BEGIN {EXCLUSIVE}
ASSERT((state = 1) OR (state = 2));
state := 2
END Start;

PROCEDURE Stop;
BEGIN {EXCLUSIVE}
ASSERT((state = 2) OR (state = 1));
state := 1
END Stop;

PROCEDURE Terminate;
BEGIN {EXCLUSIVE}
state := 3;
time.Wakeup
END Terminate;

PROCEDURE AwaitTermination;
BEGIN {EXCLUSIVE}
AWAIT(state = 4)
END AwaitTermination;

PROCEDURE State (): SHORTINT;
BEGIN {EXCLUSIVE}
RETURN state
END State;

PROCEDURE Activate;
BEGIN
BEGIN {EXCLUSIVE}
INC(activations)
END;
(* ...some code... *)
END Activate;

PROCEDURE Log (s: ARRAY OF CHAR);
BEGIN
AosOut.String("object["); AosOut.Int(id, 0); AosOut.String("]: "); AosOut.String(s); AosOut.Ln
END Log;

PROCEDURE Activations (): INTEGER;
BEGIN {EXCLUSIVE}
RETURN activations
END Activations;

BEGIN {ACTIVE}
LOOP
IF state = 3 THEN EXIT END;
time.Sleep(rgen.Timeout());
IF state = 2 THEN
Activate;
IF activations = 1000 THEN EXIT END
END
END;
BEGIN {EXCLUSIVE}
state := 4
END
END A;

VAR rgen: RGen;
a: ARRAY N OF A;

PROCEDURE Start* (par: ANY): ANY;
VAR i: INTEGER;
BEGIN
AosOut.String("AixDoorways.Start: started"); AosOut.Ln;
FOR i := 0 TO N-1 DO
a[i].Start
END;
AosOut.String("AixDoorways.Start: done"); AosOut.Ln;
RETURN NIL
END Start;

PROCEDURE Stop* (par: ANY): ANY;
VAR i: INTEGER;
BEGIN
AosOut.String("AixDoorways.Stop: started"); AosOut.Ln;
FOR i := 0 TO N-1 DO
a[i].Stop
END;
AosOut.String("AixDoorways.Stop: done"); AosOut.Ln;
RETURN NIL
END Stop;

(* statistics *)
PROCEDURE Activations* (par: ANY): ANY;
VAR i: INTEGER; activations: LONGINT;
BEGIN
AosOut.String("AixDoorways.Activations: ");
activations := 0;
FOR i := 0 TO N-1 DO
INC(activations, a[i].Activations())
END;
AosOut.Int(activations, 0); AosOut.Ln;
RETURN NIL
END Activations;

(* create objects *)
PROCEDURE Initialize;
VAR i: INTEGER;
BEGIN
AosOut.String("AixDoorways.Initialize: started"); AosOut.Ln;
NEW(rgen);
FOR i := 0 TO N-1 DO
NEW(a[i], i); a[i].Create
END;
AosOut.String("AixDoorways.Initialize: done"); AosOut.Ln
END Initialize;

(* terminate objects *)
PROCEDURE Cleanup;
VAR i: INTEGER;
BEGIN
AosOut.String('AixDoorways.Cleanup: started'); AosOut.Ln;
FOR i := 0 TO N-1 DO
a[i].Terminate
END;
FOR i := 0 TO N-1 DO
a[i].AwaitTermination; a[i] := NIL
END;
AosOut.String('AixDoorways.Cleanup: done'); AosOut.Ln
END Cleanup;

BEGIN
AosModules.InstallTermHandler(Cleanup);
Initialize
END AixDoorways.

S.Free AixDoorways ~

AixDoorways.Start

AixDoorways.Stop

AixDoorways.Activations