Как лучше решить эту ООП задачу?

Question

[Urukhayy]

Есть классы: University и Professor.
University содержит множество экземпляров Professor.
У Professor должен быть метод getUniversity, возвращающий University.

Как можно правильно по ООП решить эту задачу? При этом, Professor не должен хранить в себе ссылку на экземпляр университета, ведь это агрегация, и профессор может существовать в отсутствие университета, поэтому ссылка на университет может быть всегда пустой. Более того, нарушается принцип SOLID (OCP): если в будущем мы захотим добавить College и профессор должен будет работать сразу в двух учебных заведениях.

Comments

[Виталий Витренко]

Рекомендую sergeyteplyakov.blogspot.com/2014/08/open-closed-p...

Answer 1

[GavriKos]

А ваш метод GetUniversity у профессора не нарушит SOLID и агрегацию? По моему тут обычный DI - инжектируйте зависимость в профессора, просто не через конструктор, а через поле, раз профессор может туда-сюда бегать из университета в колледж.

Comments

[Urukhayy]

Представьте, что класс Профессоров пишут за 3 года до Университетов. И вообще те, кто пишут университеты, не знаю о том, что кто-то напишет профессоров. И пишут их разные группы людей. И Профессоры -- это модульная структура, которая интегрируется в разные программы, не только под Университеты.

[Urukhayy]

Другими словами: есть группа людей, которая пишет Университеты. Они их пишут, и хотят интегрировать к ним Профессоров. А Профессоры -- Немутирующий класс. Но их нужно подключать как-то к университетам.

[Urukhayy]

Метод нарушит, но я привел его в пример. Нужно как-то через профессора выходить на Вуз, в котором он в данный момент есть. Есть более эффективные способы, чем просто перебор ВУЗов?

[GavriKos]

Urukhayy раз профессоров пишут за 3 года до университетов - то у профессора не должно быть ни метода GetUniversity, ни вообще ссылки на университет. Отсюда два варианта - либо у университета есть метод вида "IsProfessorInUniversity", принимающий указатель на профессора, либо вообще есть отдельный класс, заведующий всеми этими связями.

[Urukhayy]

Вот. Об этом я и спрашиваю, как лучше организовать с точки зрения ООП все эти заведующие связи. Есть ли способ лучше, чем просто циклом проходиться по ВУЗам?

[GavriKos]

Urukhayy внешний класс, в котором есть словарь, где ключ - это профессор, а значение - список ВУЗов, в которых он работает. И будет без всякого поиска.

[GavriKos]

Urukhayy Это конечно достаточно костыльное решение - по хорошему вам тогда все методы. отвечающие за связку профессоров и ВУЗов надо держать в этом классе.

[Urukhayy]

GavriKos: А есть способ держать прямую ссылку на Вуз где-либо?

[GavriKos]

Urukhayy не понял вопроса. Я же выше вам структуру описал, в которой прямые ссылки на вузы.

Answer 2

[Артем Спиридонов]

University содержит множество экземпляров Professor.

В смысле? Университет может порождать множество экземпляров университетов, а профессор - профессоров. И они не могут наследовать - профессор не имеет ни свойств, ни методов университета.

Как верно подсказал коллега выше, принадлежность к университету - обычное свойство профессора, причем может быть многие-ко-многим. Следовательно, ответ на ваш вопрос: обычный геттер.

Comments

[Urukhayy]

Содержание множества экземпляров -- есть коллекция профессоров в качестве поля у каждого экземпляра университета.

[Urukhayy]

Я неверно привел метод в пример. Профессоры -- немутирующий класс. Если колледж создадут после того, как профессоров напишут, их нельзя уже править и вписывать "геттеры".

[Артем Спиридонов]

Urukhayy: у университета нет кортежа профессоров. Есть кортеж связей

Answer 3

[asd111]

1 . Делать отдельный массив из словарей university - professor. Когда появятся College, то нужен будет ещё один массив college-professor. Для поиска нужно будет обходить весь массив. Менять класс профессора не понадобится при появлении коледжей.
2. Хранить массив профессоров в каждом универе и массив универов в каждом профессоре. При добавлении колеждей нужно будет менять класс профессора.

Первое решение универсальнее, соответствует нормальным формам проектирования БД и часто используется при проектировании БД, т.е. когда появится БД, а она судя по всему появится, то перенести все в БД будет просто.