ООП. Удаление циклической связанности #608387

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

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

кто нибудь занимается проектированием классов?

злые..

Тут все одноэсники. Вы ошиблись форумом.

Не надо так говорить... мы не злые... 1. нет ничего невозможного 2. все по логике проектированием занимаются все, кто кода-нибудь разрабатывал с нуля

неугомонный: всё ресурсоконтекстнозависимо

а почему бы сразу без циклических ссылок не спроектировать?

пример. Учитель сообщает ученику задание (учитель знает об ученике), ученик решает задание и говорит его ни кому нибудь, а именно своему учителю (ученик знает, кому надо сообщить)

тут не о сабже

тишина... асинхронная обработка сообщений решит все ваши проблемы...

а это тут зачем?

ссылка на учителя в задании, между учителем и учеником вообще не должно быть ссылок, у ученика есть коллекция заданий

у учителя есть ссылка на курсы, которые он ведет, у групп есть ссылки на курсы, у ученика есть ссылка на группу

ок, тогда Задание ссылается на Учителя Учитель имеет понятие, какое Задание он выдает и связь тоже есть В итоге снова цикл

ты не фантазируй, я тебе пример привел, разруливай

а это глобально, или укажи язык, в пределах которого танцевать. IRL циклические зависимости везде!

язык?можно любой из следующих: Delphi, C++, C#

пример копропроектирования, если так проектировать, то конечно надо задумываться над темами типа

а что у нас ооп, сильно различается в контексте этой задачи в разных языках?

внекоторых случаях сильно

я прошу спроектировать решение для или

+ опять же, я говорю обо всех языках, в том числе о ещё не спроектированных

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

твой концепт сильнее моего ))

;)

конкретный пример различий можно?

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

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

ну это такой пунктик, как с неопределено и NULL

это к ненавижу, он видимо не только 1С ненавидит)

ссылка это не только поле/свойство класса, это осведомленность класса о другом классе class Teacher { Job* CreateJob; //учитель осведомлен о заданиях } class Job { Teacher* teacher; //задание знает, кто его выдал }

ну придумайте класс менеджер и вынесите всю логику туда

я попросил конкретный пример различия в контексте данной задачи, а не ссылку на вики

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

ссылок*

показывай как надо

на C++ и Lisp данную "задачу" можно обыграть очень по-разному

есть учитель есть ученик есть задача есть задача_выданная_учителем_ученику - это отдельный класс

первый вариант: к примеру учителю надо раздать и собрать задания, в таком случае целесообразно хранить ссылки на задания у учителя, и методы раздать и собрать будут работать с приватными коллекциями

хорошо начал

простите, но класс с объектом не надо путать

казалось бы причем тут лисп и ооп?

он пока не путает ничего, имхо

а кто путает

мммм?????

почему?

второй вариант, ученик получает задание и сдает его учителю в этом случае оптимально хранить ссылку на учителя в задании, а коллекцию заданий в классе ученик

угадай! )

все равно циклы

задача, и задача_выданная_учителем_ученику ... это что такое? либо избыточная иерархия, вообще не нужная для данной задачи, либо путаем класс и его инстанс)

ClassBX is a ClassCX, так что все эти манипуляции не имеют смысла.

izekia у тебя в институте логику преподавали?

ммм, где ты увидел, покажи?

да, все кроме программирования

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

ну да

чот не похоже. какую-то ахинею несешь. в мы выделяем объекты = это ученик, учитель, задача. и отношения. учитель выдал ученику задачу. это отношение, которое мы выделяем в отдельный класс в терминах С++.

есть учитель есть ученик есть задача есть задача_выданная_учителем_ученику - это отдельный класс добаляем класс - синглтон Менеджер задач  - и вуаля. Учителю надо выдать ученику задачу - опращаемся в менеджер и тот создает инстанс класса задача_выданная_учителем_ученику Ученик хочет сдать задачу - обращается в менеджер и сдает устраивает?

а почему супервайзер  - это суперкласс учителя а не ученика?

угу, офигенно классно, а чтобы знать какому супервайзеру сообщить о задаче мы еще один класс создадим в чем выигрыш?

НЕТ ЦИКЛИЧЕСКИМ ССЫЛКАМ!!!! я так понимаю

то есть отношение просто хранит три ссылки?

ну типа того. Прямой перенос таблицы отношений на структуру классов

угу

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

=> нет такого объекта, как отношение

зато парсер писать не надо....

есть. у него ещё и тонна свойств может быть

к тому же вопрос о том есть такой объект как отношение или нету - я для себя не решил. Может кто извеликих на эту тему высказывался?

в Лиспе?)

в C# например

ну какой ты 1С ник?

да как решение с точки построения бд, оно вполне изящно, просто классы не обязательно должны копировать структуру бд

нене, надо в Лиспе)

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

лисп - это для меня слишком сложно... да и денех за него не плотют вроде... не должны. Но часто копируют. Это же удобно базу то мы проектируем исходя из реальных объектов - вполне логичненько перенести эту структуру на слой бизнес логики

а где в твоем рассуждении структура бд?

мы тут извращаемся в рамках поставленной автором задачи я вот лично не представляю себе зачем в реальности мне бы понадобилось от них избавляться и заморачиваться по их поводу на этапе проектирования

лисп и ооп лежат в разных плоскостях

это скорее мой прием как одноэснега бывшего по проектированию классов: сначала представь как бы ты хранил данные системы в таблицах. А потом преобразуй таблички в классы. Но вы совершенно правы - в описании задачи нет никакого указания на базу данных

ок. Не знаю и ничего не желаю знать про лисп

лисп - метаязык. он лежит более в области ооп чем С++, это уж точно

как это зачем? а классика? модель не должна ничего знать о представлении и т.д.

да речь о том, что хирашима хотел решать поставленную абстрактную задачу про классы на лиспе, предварительно еще пихнув ссылку на обджектив си зачем-то

её можно решать хоть на асме

event спасет отца русской демократии. Это если вы про MVC

пример класса кружка на лиспе можно? три метода: Добавить, Отлить, ПолучитьОбъемЖидкости

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

не надоело еще чушь нести?

наверное... я так глубоко не интересовался....

ты ничерта не понимаешь в ООП

а что, это сложно???? я совершенно искренне спрашиваю...

ну ты почему не хочешь понять, что я уже давно написал ... ты привел пример трех объектов из реальной жизни, на самом деле у них может быть столько функциональности, которой их можно напичкать, и которая в рамках конкретной задачи вообще не будет нужна, нужно исходить из необходимой функциональности и проектировать соответственно

лол

"и он ещё улыбается")

я смеюсь во весь голос скорее, видимо что означает данная аббревиатура, Вы так же хорошо знаете можно пример такого класса на классическом лиспе?

первых двух абзацев должно хватить для понимания того о чем речь

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