Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2015.12.27;
Скачать: [xml.tar.bz2];

Вниз

Досоздать наследованный класс позже   Найти похожие ветки 

 
Кто б сомневался ©   (2015-05-01 20:49) [0]

Есть TFileItemStorage - там хранятся связанные с файлами данные.
Этих классов много создается.

От него отнаследован TProcessItem (TFileItemStorage)  - которые используется редко, только когда нужно запустить процесс exe  или ассоциированный с файлом процесс.
Т.е. создавать TProcessItem, вместо отдельного TFileItemStorage нет смысла - будет висеть мертвым грузом - а там много разных полей..

Можно ли в Delphi как то подцепить TProcessItem к уже существующему TFileItemStorage? Тэк сказать "досоздать" класс?

Или придется создавать как обычно TProcessItem.Create, а потом делать Assign с TFileItemStorage?


 
Кто б сомневался ©   (2015-05-01 20:55) [1]

Почему классно бы было досоздавать класс (я просто такой возможности не знаю, но мало ли мож че пропустил) - в списках Tlist не нужно было бы обновлять его адрес, и вообще перебрасывать данные через Assign.


 
Ega23 ©   (2015-05-01 20:59) [2]

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D0%B5%D1%82%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_%28%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%29

?


 
кгшзх ©   (2015-05-01 21:02) [3]

у тебя что, сейчас денег нет на полное описание класса?


 
Кто б сомневался ©   (2015-05-01 21:19) [4]


> кгшзх ©   (01.05.15 21:02) [3]
>
> у тебя что, сейчас денег нет на полное описание класса?


У кого то могут не быть.
А много по малу = много = а это потом выльется в тормоза..


 
Rouse_ ©   (2015-05-01 21:25) [5]

Альтернативный конструкор, быстро, дешево, без изысков


 
Rouse_ ©   (2015-05-01 21:27) [6]

Мне просто лень щас к компу идти и писать демо-код, но идея думаю понятна


 
Кто б сомневался ©   (2015-05-01 21:32) [7]


> Rouse_ ©   (01.05.15 21:25) [5]
>
> Альтернативный конструкор, быстро, дешево, без изысков


Ну это тот же assign по факту. Ссылку на класс в списках придется все равно как то менять.


 
Rouse_ ©   (2015-05-01 21:34) [8]

Есть нюанс., но я позже обьясню - уже убегаю


 
Кто б сомневался ©   (2015-05-01 21:46) [9]

О можно еще так сделать.
В TProcessItem добавить поле PRecord, в record кинуть все поля и массивы этого класса, и сделать метод Init - можно выделять весь рекорд в Init динамически. И можно создавать весь класс целиком TProcessItem для всех.


 
Юрий Зотов ©   (2015-05-02 06:43) [10]

Если я правильно понял задачу, то здесь нужно не наследование, а агрегация.


 
Юрий Зотов ©   (2015-05-02 09:46) [11]

> подцепить TProcessItem к уже существующему TFileItemStorage?

type
 TProcessItem = class
 private
   FFileItemStorage: TFileItemStorage;
   ...
 public
   ...
   property FileItemStorage: TFileItemStorage
     read FFileItemStorage write FFileItemStorage;
   ...
 end;
 ...
 Item := TFileProcessItem.Create;
 Item.FileItemStorage := Storage; // Storage уже существует

Вот и подцепили. Теперь все свойства и методы уже существующего Storage стали доступны свежесозданному Item"у через его свойство FileItemStorage. Все очень просто и без всяких Assign. И "переподцепить" к другому FileItemStorage можно. А если такое "переподцепление" недопустимо, то слегка изменим код:

type
 TProcessItem = class
 private
   FFileItemStorage: TFileItemStorage;
   ...
 public
   constructor Create(AFileItemStorage: TFileItemStorage);
   ...
   property FileItemStorage: TFileItemStorage read FFileItemStorage;
   ...
 end;

constructor TFileProcessItem.Create(AFileItemStorage: TFileItemStorage);
begin
 inherited;
 FFileItemStorage := AFileItemStorage
end;
 ...
Item := TFileProcessItem.Create(Storage); // Storage уже существует


 
картман ©   (2015-05-02 10:59) [12]


> Юрий Зотов ©   (02.05.15 09:46) [11]


судя по:

> в списках Tlist не нужно было бы обновлять его адрес


Ваше решение нужно вывернуть наизнанку


 
Юрий Зотов ©   (2015-05-02 11:39) [13]

> картман ©   (02.05.15 10:59) [12]

Почему?

Если в списке хранится адрес TProcessItem , то от назначения ЕМУ свойства FileItemStorage его адрес не изменится - значит, обновлять ничего не надо.

Если же в списке хранится адрес TFileItemStorage, то от назначения ЕГОсвойству FileItemStorage его адрес тоже не изменится - значит, снова обновлять ничего не надо.


 
картман ©   (2015-05-02 12:33) [14]


> Юрий Зотов ©   (02.05.15 11:39) [13]
>
> > картман ©   (02.05.15 10:59) [12]
>
> Почему?
>
> Если в списке хранится адрес TProcessItem

а он:

> От него отнаследован TProcessItem (TFileItemStorage)  -
> которые используется редко, только когда нужно запустить
> процесс exe  или ассоциированный с файлом процесс.
> Т.е. создавать TProcessItem, вместо отдельного TFileItemStorage
> нет смысла - будет висеть мертвым грузом - а там много разных
> полей..

т.е. по умолчанию нужен TFileItemStorage и в редких случаях нужно заменять уже существующий TFileItemStorage на TProcessItem , но при замене первого на второй нужно, чтоб ссылка оставалась прежней.

Я так понял)) Будь иначе, автор бы и не задал такой вопрос, как мне кажется))


 
картман ©   (2015-05-02 12:35) [15]


> Юрий Зотов ©   (02.05.15 11:39) [13]

невнимательно прочитал, но, как я понял, ему нужно менять первый на второй - именно менять


 
Кто б сомневался ©   (2015-05-02 21:42) [16]

Суть в том что я не хочу чтобы класс TProcessItem был лишний раз создан, т.к. там в private куча полей и массив  - они отберут кусок памяти.


> Юрий Зотов ©   (02.05.15 09:46) [11]


Да но для этого придется создавать TProcessItem для всех  (а сейчас они как TFileItem) - т.к. нужен доступ где нибудь выше, где есть только список TFileItem.

Плюс наследование теряется - там еще есть общие методы (типа добывание иконки, или имени процесса если запустили ассоциированный файл)

Вот у меня где то там есть список TFileItemStorage. Часть может быть запущена и тогда создан TprocessItem, а часть нет. Если она запущена, то TprocessItem класс должен быть.

В TFileItemStorage нельзя добавить TProcessItem - т.к. юниты будут пересекаться в interface компилятор будет ругаться, да и не нужно особо.

Вобщем я решил просто в списке Tlist менять старый класс TFileItemStorage на новый - TProcessItem (создавать и делать assign, а пред. класс уничтожать - это не проблема), а если позже понадобится выйти на TprocessItem - в TFileItemStorage сделать флаг - инициирован ли класс TProcessItem или нет, и с ним можно работать, а после обращаться к нему прямым приведением - TprocessItem(List[i] ). Т.е. в списке TLIst будут и классы  TFileItemStorage и TProcessItem (которые наследуются от TFileItemStorage) .
Как вам такой вариант?

Или [9], но как то это неудобно.



Страницы: 1 вся ветка

Форум: "Прочее";
Текущий архив: 2015.12.27;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.49 MB
Время: 0.001 c
15-1430653980
Kerk
2015-05-03 14:53
2015.12.27
GPRS


3-1306138163
vv_fran
2011-05-23 12:09
2015.12.27
Как сообщение RAISERROR из ХП показать пользователю на экране?


15-1430256605
Юрий
2015-04-29 00:30
2015.12.27
С днем рождения ! 29 апреля 2015 среда


15-1430547032
картман
2015-05-02 09:10
2015.12.27
проигрыватель в мозиле


15-1430470684
Fox
2015-05-01 11:58
2015.12.27
Аналог IdHTTP1.Post на Java





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский