Шарики, ООП Опции

[Bokul]

Тема зародилась Задачник по ООП, а это ее продолжения.
Вот структура того, что я написал (измененная)

1 TGObject -// движущейся графический объект, умеет: 
    // - инитиализировать себя 
    constructor init(speed,color:byte; angle,time:real);
    // - двигаться 
    procedure   moveto;
    //- высчитывать свое новое положение, перекрывается в наследниках
    procedure   calculation; virtual; //abstract; 
    //- вызывается с Supervisor, только в случае столкновения.
    //  Меняем скорость и угол полета.
    procedure   ChangeDirection(speed:byte; angle:real);
    // рисуем себя, перекрывается в наследниках
    procedure   show; virtual; // abstract; 
    // стираем себя, перекрывается в наследниках
    procedure   hide; virtual; // abstract;
    // стирает себя с экрана
    destructor  done; virtual; 

2 TBall - наследник TGObject, теперь это движущейся шарик
     // - добавили новое поле r -радиус, инициализацию остальных полей наследуем
     constructor init(x,y:integer; speed,color:byte; angle,time:real; r:byte);
      procedure   moveto;// перекрываем, наслудуем
      procedure   calculation; virtual;// перекрываем 
      procedure   show; virtual; // тоже перекрываем
      procedure   hide; virtual; // тоже перекрываем
      destructor  done; virtual; // перекрываем, наслудуем
    
  
 3 TItem - элемент списка указателей на  объекты TBall 
     //  инициализирует свою информационную часть
     constructor constructor init(Info:TPGObject; Sled:TPItem);
     destructor  done;// удаляем информационную часть

4 TList - содержит список указателей на объеты типа TBall 
    constructor init;//-инициализирует список
    function     AddItem(Data:TPGObject):boolean; // добавляем новый элемент
    function    DeleteItem(pdel:TPItem):boolean; // удаляем элемент
    destructor  done;//удаляем весь список

Исходники в виде модулей для FPC -  Balls.rar ( 15.06 килобайт ) Кол-во скачиваний: 503



Возникли затруднения в написания модуля TSupervisor, а именно с главным циклом и наследием этого объекта.
Вот, что я написал

uses objects,graphl,UnitTGObject,UnitList;
const
  background=black;
  ballcolor=red;


{------------------------TSupervisor------------------}
type
  TPSuperVisor=^TSuperVisor;
  TSuperVisor=object
     GObjectsList:TList;
     Rect:TRect;
     constructor init(xa,ya,xb,yb:integer);
     function    AddGObject(p:TPGObject):boolean;
     function    DeleteGObject(p:TPGObject):boolean;
     function    ChangeDirection;
     function    Calculation;
     function    WriteResults;
     procedure   main;
     destructor  done;
  end;
constructor TSuperVisor.init;
begin
  GObjectsList.init;
  Rect.assign(xa,ya,xb,yb);
  SetColor(white);
  Rectangle(xa,ya,xb,yb);
end;

function TSuperVisor.AddGObject(p:TPGObject);
begin
  AddGObject:=GObjectsList.AddItem(p);
end;

function TSuperVisor.DeleteGObject(p:TPGObject):boolean;
begin
  DeleteTPGObject:=GObjectsList.DeleteItem(p);
end;

procedure TSuperVisor.main;
begin
end;

destructor TSuperVisor.done;
begin
  GObjectsList.done;
  ClearDevice;
end;

[volvo]

Я тоже согласен оставить эти методы абстрактными в TSuperVisor и переопределять их в наследниках.

А вот с этого места - поподробнее... Что это будут за наследники от TSuperVisor? СуперНаблюдатели? НаблюдателиСПравомВмешатьсяИПредотвратитьСтолкновение? Что ты вкладываешь в смысл "унаследоваться от объекта" в этом случае? Какие это тебе даст преимущества? Шарики будут так же кататься? Сталкиваться? Отскакивать друг от друга? Это все будет работать и с этим же Наблюдателем, без наследников...

Понимаешь в чем дело, ведь просто так наследование - оно не панацея... Его надо применять тогда, когда это необходимо, а не потому, что оно есть в языке... Вот я и прошу тебя объяснить, ЧЕМ программа с ПЕРЕопределенным Наблюдателем будет отличаться от программы, где методы TSuperVisor будут доработаны?

Может вместо списков использовать коллекции?

Аналогично, какие ты в этом видишь преимущества? Что есть такое в коллекциях, чего нет (и нельзя сделать, заметь!!!) в списке? Только то, что там ЭТО уже готово, а для TList придется сделать - это для меня не аргумент, тем более в целях обучения... Я, конечно, против изобретения велосипедов, но вот тут как раз - не тот случай... Смотри: есть у меня коллекция. Что я могу с ней сделать (на примере TCollection)? Добавить элемент в коллекцию, найти его в коллекции, удалить оттуда, правда? А со списком все гораздо интереснее... Я же могу переопределить TList на TPriorityList, скажем, и добавлять в список объекты, согласно их приоритету... Например, для того, чтобы обработка квадратов была предпочтительнее обработки треугольников в 3 раза. И, заметь, я это полностью буду контролировать, ибо ЭТО - написано мной, а не кем-то, возможно, даже, лучше меня программирующим, НО не знающим специфики моего приложения... Мне, например, может быть критична скорость операции добавления в список, а по какому критерию оптимизированы коллекции, ты можешь мне гарантировать? Я, наконец, список элементарно заменю на дерево, если надо будет... Так что ТАКИЕ вещи я предпочитаю делать сам; если ты хочешь пользоваться готовым - дело твое, только потом НЕ говори, что я тебя НЕ предупреждал, когда тебе станет не хватать скорости обработки, или емкости коллекции (ну, это - вряд ли, они достаточно вместительны), или гибкости ее... (Если тебя прельстил метод ForEach, то это тоже преодолимо, как ты помнишь...)

Ты хочешь передавать в TGObject точку, где он столкнулся, а все остальное пусть высчитывает сам?

Да я бы вообще ничего не передавал... Чего, объект своего положения не знает? Зачем еще ему что-то передавать? Надо просто вызвать процедуру обработки столкновения двух объектов (причем она совершенно не обязательно будет методом TSuperVisor, я бы как раз ее сделал посторонней процедурой), а там уже пускай в зависимости от формы и свойств столкнувшихся объектов она разруливает, какой процент энергии будет потерян, и какой объект получит импульс под каким углом (и как именно она это будет делать - тоже никоим образом Наблюдателя не касается - это не его проблема, он Наблюдатель!!! Зафиксировал факт столкновения - сообщил, куда следует. Все, спасибо, продолжай наблюдать)... А дальше - прямая обязанность объекта - пересчитать свои координаты с учетом новых данных...