Циклическая зависимость классов / Delphi

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Delphi [игнор отключен] [закрыт для гостей] / Циклическая зависимость классов

16 сообщений из 16, страница 1 из 1

Циклическая зависимость классов

#39732374

fckr

Гость

Как лучше решить проблему циклических зависимостей классов? Например, есть многопользовательская игра. Такие классы:

Код: pascal

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

TPlayer = class
    units: TArray<TUnit>;
    color: cardinal;
    ...
end;

TUnit = class
    owner: TPlayer;
    ..,
end;

Разумеется, оба класса записаны в разных модулях. При выводе изображения объект класса TUnit обращается к объекту TPlayer для получения цвета игрока (имени или любого другого параметра, относящегося непосредственно к игроку). Это создает циклическую зависимость: в разделе uses одного модуля вызывается другой, и наоборот.

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

В моем примере выше, дублировать поле "color" (и любые другие требуемые поля) в классе TUnit было бы неправильно. Каким образом правильно (с точки зрения структуры) разорвать эту циклическую зависимость (либо, просто решить проблему)? Наверняка, многие с этим сталкивались.

...

Рейтинг:

0 / 0

13.11.2018, 13:03

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732377

JayDi

Участник

Откуда: Сызрань, Россия

Сообщения: 4 243

Рейтинг: 0 / 0

fckrИнтересует именно этот совет: неужели, всегда можно красиво и правильно разорвать эту циклическую зависимость?
Да.

...

Рейтинг:

0 / 0

13.11.2018, 13:07

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732397

Dimonka

Участник

Сообщения: 1 194

Рейтинг: 0 / 0

fckr,

Ты можешь выделить интерфейсы обоих классов и вынести их в один (третий) юнит, а реализацию интерфейсов и обращение друг к другу через вынесенные интерфейсы в разных юнитах.

...

Рейтинг:

0 / 0

13.11.2018, 13:21

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732411

GunSmoker

Участник

Сообщения: 3 366

Рейтинг: 0 / 0

Возможно, будет интересно: "Дружественность" в Delphi

...

Рейтинг:

0 / 0

13.11.2018, 13:40

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732440

Dimitry Sibiryakov

Участник

Сообщения: 54 521

Рейтинг: 0 / 0

fckrЕсть, также, совет "изменить структуру программы, потому что ссылка на родителя - плохой
тон". Интересует именно этот совет: неужели, всегда можно красиво и правильно разорвать
эту циклическую зависимость?

Не всегда, но в большинстве случаев это удаётся правильным дизайном иерархии классов и их
взаимодействия. В твоём случае достаточно убрать из TPlayer список его юнитов, поскольку
удобнее иметь один общий список юнитов в игровом мире. Возможно, сгруппированный по
владельцам, которыми могут быть не только игроки, но и NPC, например.
Posted via ActualForum NNTP Server 1.5

...

Рейтинг:

0 / 0

13.11.2018, 14:17

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732571

Василий 2

Участник

Сообщения: 1 021

Рейтинг: 0 / 0

В какой это вселенной ссылка на родителя - плохой тон?

По твоему конкретному случаю: я бы выделил отдельный тип TPlayerProps, которые нужны юниту от плеера.

...

Рейтинг:

0 / 0

13.11.2018, 16:50

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732576

wadman

Участник

Откуда: Санкт-Петербург

Сообщения: 26 163

Рейтинг: 0 / 0

fckr

Код: pascal

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

TPlayerAbstract = class
    units: TArray<TUnitAbstract>;
    color: cardinal;
    ...
end;

TUnitAbstract = class
    owner: TPlayerAbstract;
    ..,
end;

Можно вынести эти два класса на абстрактном уровне в свои модули.
В других-же модулях их реализовать с любыми ссылками.

...

Рейтинг:

0 / 0

13.11.2018, 16:54

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732895

Valery_B

Участник

Откуда: Москва

Сообщения: 2 096

Рейтинг: 0 / 0

Эта задача про Корзину с яблоками.
На корзине написано, сколько и каких яблок в ней лежат, а на яблоках - в какой корзине они лежат

DimonkaТы можешь выделить интерфейсы
Да.
Но если далее работать с объектами через интерфейс, то получается, что яблоки всегда ссылаются на корзину, а корзина - на яблоки.
т.е. объекты ссылаются сами на себя и освобождения интерфейса не произойдёт.
Микрософт подумала, и решила эту проблему созданием среды .NET :)

На Delphi можно сделать так:

Код: pascal

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

  TUnit = class; //Добавить вот эту строчку.

  TPlayer = class
    units: TArray<TUnit>;
    color: cardinal;
   end;

  TUnit = class
    owner: TPlayer;
  end;

Но я бы лучше подумал на сколько это целесообразно.

...

Рейтинг:

0 / 0

14.11.2018, 11:36

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732907

Василий 2

Участник

Сообщения: 1 021

Рейтинг: 0 / 0

Valery_BНа Delphi можно сделать так:

Код: pascal

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

  TUnit = class; //Добавить вот эту строчку.

  TPlayer = class
    units: TArray<TUnit>;
    color: cardinal;
   end;

  TUnit = class
    owner: TPlayer;
  end;

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

...

Рейтинг:

0 / 0

14.11.2018, 11:49

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732939

kealon(Ruslan)

Участник

Откуда: Нижневартовск

Сообщения: 4 020

Рейтинг: 0 / 0

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

у меня есть два простых совета:
собрать зависимые объекты в один модуль и не париться с глупостями

для автоматизации сделать генерики владетель-владеемый в отдельном модуле и уже от их конкретной специализации наследоваться

...

Рейтинг:

0 / 0

14.11.2018, 12:38

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732969

Valery_B

Участник

Откуда: Москва

Сообщения: 2 096

Рейтинг: 0 / 0

kealon(Ruslan)советчиков полно

kealon(Ruslan)у меня есть два простых совета:

Во, теперь их стало на одного больше )

...

Рейтинг:

0 / 0

14.11.2018, 13:29

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39732983

rgreat

Участник

Сообщения: 7 255

Рейтинг: 0 / 0

Еще вариант

Код: pascal

1.
2.
3.
4.

TUnit = class
    owner: TPlayer;
    ..,
end;

заменить на

Код: pascal

1.
2.
3.
4.

TUnit = class
    owner: TObject;
    ..,
end;

И где надо делать приведение типов.

...

Рейтинг:

0 / 0

14.11.2018, 13:40

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39733020

Квейд

Участник

Откуда: Kyiv, Ukraine

Сообщения: 5 686

Рейтинг: 0 / 0

Valery_BЭта задача про Корзину с яблоками.
На корзине написано, сколько и каких яблок в ней лежат, а на яблоках - в какой корзине они лежат

DimonkaТы можешь выделить интерфейсы
Да.
Но если далее работать с объектами через интерфейс, то получается, что яблоки всегда ссылаются на корзину, а корзина - на яблоки.
т.е. объекты ссылаются сами на себя и освобождения интерфейса не произойдёт.

Код: pascal

[weak]

не предлагать?

...

Рейтинг:

0 / 0

14.11.2018, 14:27

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39733021

kealon(Ruslan)

Участник

Откуда: Нижневартовск

Сообщения: 4 020

Рейтинг: 0 / 0

Квейд,

много народу под ARC пишет? можно вообще забить на такие глупости

...

Рейтинг:

0 / 0

14.11.2018, 14:29

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39733092

X-Cite

Участник

Откуда: Минск

Сообщения: 1 886

Рейтинг: 0 / 0

Слабость ссылки можно сэмулировать через присвоение
Вместо:

Код: pascal

1.
2.
3.
4.

var
  a, b: IInterface;

a := b;

прописать

Код: pascal

Pointer(a) := Pointer(b);

Важно только понимать кто должен освободиться раньше, а кто позже.

...

Рейтинг:

0 / 0

14.11.2018, 16:04

| Ответить | Цитировать | Написать

Циклическая зависимость классов

#39733104

Dimonka

Участник

Сообщения: 1 194

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

14.11.2018, 16:24

| Ответить | Цитировать | Написать

16 сообщений из 16, страница 1 из 1

Форумы / Delphi [игнор отключен] [закрыт для гостей] / Циклическая зависимость классов

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=58&msg=39732939&tid=2040127]:	0ms
get settings:	7ms
get forum list:	11ms
check forum access:	3ms
check topic access:	3ms
track hit:	41ms
get topic data:	10ms
get forum data:	2ms
get page messages:	47ms
get tp. blocked users:	1ms
others:	204ms

total:	329ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы