@GSerge

Всем привет! Недавно решил углубить знания в ООП. Надоело костыли писать, которые к тому же потом не расширить((
Придумал небольшой пример и на этапе проектирования зашел в тупик.

Система договоров. Имеет стороны - между кем заключается договор. Также имеет "условия" договора - задачи сторон.
Например. Есть электрик(физ. лицо) и магазин(юр. лицо). Магазин заключает договор с электриком на установку розетки(задача). Электрик должен выполнить работу, а магазин должен ее оплатить.



Так вот. Как по правильному сделать, что-бы классы ссылались друг на друга. Лицо должно знать о своих Договорах. Так же как Договор должен знать о Лицах, подписавших его. Что-бы Электрик знал.. через договор.. Магазин со сломанной розеткой.
У договора может быть от двух и больше сторон. У лиц так же может быть много разных договоров.

Что это за связь? через что она реализуется? Или может у меня структура не верная?

С точки зрения ООП.

0

@Fulcrum_013

В этих делах нужно смотреть с точки зрения теории принятия решений. Т.е. решения принимает тот объект который имеет всю полноту данных необходимых для принятия решений. Ну и соответсвенно ссылки должны быть на всех с кого он эти данные должен получить и кого о своих решениях оповестить. В общем то на этом все паттерны и построены.
В общем то так или иначе что то в духе обсервера. Вообще современные иерархии в основном вокруг композит+обсервер+лигтвеигхт крутятся.
Так что двунаправленные связи скорее норма чем странность. Странность обычно если их нет. К примеру искоробочные фреймверки дельфы полностью на таких двунаправленных взаимосвязях живут
А реализуется в зависимости от языка, но как бы в любом наборе это указатель на другого в каждом из классов и механизм установки и разрыва взаимосвязи. В примитивных языках уровня Симулы (Java, С#, Delphi и т.п.) оный механизм взаимосвязей обычно пишется вручную вручную для каждой конкретной двунаправленной связи. В современных в духе С++ можно и автоматику для этого дела соорудить.

1

@Shamil1

В класс Договор добавляете свойство "Список лиц (стороны)". В класс Лицо добавляете свойство "Список договоров".

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

Добавлено через 5 минут
В "примитивных" языках обычно используются ORM.

1

@GSerge

Спасибо большое. Новые интересные слова, не знал о них((

Вот думаешь что умеешь программировать (это я о себе). Делаешь разные проекты. И все вроде бы хорошо) До момента расширения функционала))

Как же много того, чего я еще не знаю) Пишу на C#. Надеюсь мне это поможет с двунаправленной связью)

Чем больше знаешь - тем больше понимаешь, что ничего не знаешь)) Спасибо)

0

@zoom59rus

Не давно читал о таком приеме.
Есть два вида такого отношения, агрегирование и композиция.

0

@Shamil1

Агрегация и композиция не имеют отношения к теме.

0

@tmash

Привет!
Есть такое ООП
А есть такое

0

@Fulcrum_013

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

0

@tmash

Привет!
Смотрю на Ваш профиль ... сильно! Не то что я.
Вы реально не знали, что в ООП не нужны "главные", "всё знающие" объекты? И это отличает его от процедурного стиля разработки?

0

@Fulcrum_013

А кто говорит про все знающие? Речь идет как раз про то что для полиморфных типов многие решения может принимать только подчиненный, потому что главный даже типа его точного не знает. Но об этих решениях он должен так или иначе сообщать главному. Отсюда и необходимость в обратных связях.

0