Мастера DELPHI, Delphi programming community Рейтинг@Mail.ru Титульная страница Поиск, карта сайта Написать письмо 
| Новости |
Новости сайта
Поиск |
Поиск по лучшим сайтам о Delphi
FAQ |
Огромная база часто задаваемых вопросов и, конечно же, ответы к ним ;)
Статьи |
Подборка статей на самые разные темы. Все о DELPHI
Книги |
Новинки книжного рынка
Новости VCL
Обзор свежих компонент со всего мира, по-русски!
|
| Форумы
Здесь вы можете задать свой вопрос и наверняка получите ответ
| ЧАТ |
Место для общения :)
Орешник |
Коллекция курьезных вопросов из форумов
KOL и MCK |
KOL и MCK - Компактные программы на Delphi
Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / rsdn.org

 
Чтобы не потерять эту дискуссию, сделайте закладку « предыдущая ветвь | форум | следующая ветвь »

Автоматическая очистка муссора [D7]


Pavia ©   (08.01.18 15:08

Подскажите шаблон или другое решения.  Для автоматического удаления объектов.  Есть иерархическая структура: племя, семья, персона, фото.
В ходе работ создаются "копии" между которыми перетасовываются объекты.
Так вот в ходе работы постоянно создаются племена и удаляются. У каждого племени свои семь и свои персоны только фотки у разных племён общии.

При удаление племен мне надо так же удалить семью и персону.
Можно сделать это в деструкторе, но это не универсальное решение.
В будущем семья и персона так же могут принадлежать разным племенам.
Хотелось бы сделать универсальное решение. Когда не нужные объекты автоматически удаляются.

Прошу подсказать как это делается?

Верным будет решение ввести в конструктор и переменную own?
А затем в десрукторе:
Если fown=self то уничтожаем объект.
Если fown<>self то не уничтожаем объект он создан сторонним.
Если fown=nil то не уничтожаем объект он создан сторонним.



unit dcvHierarchy;

interface

uses dcvLazyBitmap;

type
 TTribe=class;
 TFamily=class;
 TPerson=class;
 TPhoto=class;

 TViClass=TFamily;   // alias

 TTribe=class
   Text:String;
   Items:array of TFamily;
 public
   function Count:Integer;
   procedure add(Family:TFamily);
   function NewFamily:TFamily;
 end;

 TFamily=class
   Text:String;
   Items:array of TPerson;
 private
   function GetPerson: TPerson;
   procedure SetPerson(const Value: TPerson);
 public
   function Count:Integer;
   procedure add(Person:TPerson); overload;
   function NewPerson:TPerson;  overload;
   procedure add(Photo:TPhoto);  overload;
   property Person:TPerson read GetPerson write SetPerson;
 end;

 TPerson=class
   Text:String;
   Items:array of TPhoto;
 private
   procedure SetPhoto(const Value: TPhoto);
   function  GetPhoto:TPhoto;
 public
   function Count:Integer;
   procedure add(Photo:TPhoto);
   function NewPhoto:TPhoto;
   procedure Assign(value:TPerson);
   property Photo:TPhoto read GetPhoto write SetPhoto;
 end;

 TPhoto=class
   Text:String;
   Bitmap:TLazyBitmap;
   procedure Assign(const Value:TPhoto);
   constructor Create;
 end;

implementation


Вайрекс   (08.01.18 16:48[1]

А почему бы не хранить все сущности в обособленных "библиотеках"? А в самих сущностях держать или ссылку на объект в библиотеке или вообще просто его индекс?
Обязательно ли совсем "удалять" или быть может стоит просто помечать как "неиспользуемая"?


Pavia ©   (08.01.18 18:55[2]


> А почему бы не хранить все сущности в обособленных "библиотеках"?
>  А в самих сущностях держать или ссылку на объект в библиотеке
> или вообще просто его индекс?

Для этого есть куча в которой всё хранится и объекты которые внутренне организованны как ссылки. А вы предлагаете лишний слой абстракции над ними. Зачем?
И то что вы обозвали библиотекей обычно называется коллекцией.

> Обязательно ли совсем "удалять" или быть может стоит просто
> помечать как "неиспользуемая"?

Проще удалять, чем помечать.  Я же с памятью работаю,а не с жёстким диском.
В дальнейшем всё может быть.


Вайрекс   (08.01.18 19:53[3]

Да какая разница - массив, список, лист, коллекция... "Библиотека" абстрактнее. :)

А как же без уровня абстракции если требуется "принадлежать разным"? Счётчик на них где будет храниться?
Если бы только "удаление иерархической ветки" да "перетасовываются" - ещё можно было бы пытаться.


Pavia ©   (08.01.18 20:10[4]


> Счётчик на них где будет храниться?

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


Вайрекс   (08.01.18 20:58[5]

А мне сложно представлять потому что я слабо понимаю цели/проблемы/задумки. Что уже есть, что возможно скоро потребуется, а что точно никогда не понадобится или более того надо запретить.

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

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


Eraser ©   (09.01.18 00:04[6]


> Pavia ©   (08.01.18 15:08) 

по-моему классическая связь многие ко многим, т.е. требуется доп. объекты/таблицы для связей.


Pavia ©   (09.01.18 05:59[7]

Племя, семья, персона, фото - эта метафора.
Мне это нужно для распознавания образов. К примеру
Племя это мебель.
Семи: стул, стол, шкаф
Персона это конкретный предмет: ваш стул, стул ребёнка, ваш стул в офисе.
А фото оно и так понятно это фото одной персоны с разных ракурсов.

Классификация, сегментация, сортировка, группировка по признакам и тп.


> по-моему классическая связь многие ко многим, т.е. требуется
> доп. объекты/таблицы для связей.

Иерархия подразумевает единоначалие. Графа нет есть деревья.  Если нужно как-то перегруппировать, то создаются(инстанцируются) новые виртуальные начала.


> должна быть в состоянии не задумываясь озвучить список своих
> "семья"?

Пока не вижу надобности делать это мгновенно. Путём обхода семей можно выяснить в которые водит персона.

> когда хорошенько всё обдумает, а пока она типа "дикая"?

Тогда достаточно own(родитель) присвоить nil.


Вайрекс   (10.01.18 02:37[8]

Я не об этом. Кто в таком случае будет хранить ссылку на объект? Он же потеряется. Для этого и то что я обозвал библиотеками.
Впрочем... Всё зависит от задачи. Оказывается всё были метафоры. :)
Задачу бы поточнее понимать, тогда и более конкретные советы будут. Поясните тогда например хоть это:

> В будущем семья и персона так же могут принадлежать разным племенам.


Игорь Шевченко ©   (10.01.18 10:23[9]

Интерфейсы же. TInterfacedObject с автоматическим подсчетом ссылок


Вайрекс   (11.01.18 03:03[10]

гм..? Любопытно, надо подумать.
Покачто нагуглил такое: https://habrahabr.ru/post/219685/
Спасибо большое за наводку.


версия для печати

Написать ответ

Ваше имя (регистрация  E-mail 







Разрешается использование тегов форматирования текста:
<b>жирный</b> <i>наклонный</i> <u>подчеркнутый</u>,
а для выделения текста программ, используйте <code> ... </code>
и не забывайте закрывать теги! </b></i></u></code> :)


Наверх

  Рейтинг@Mail.ru     Титульная страница Поиск, карта сайта Написать письмо