Как стать автором
Обновить

Комментарии 6

Вариант 1. Студент1 присутствует на курсе1.
Вариант 2. Курс1 принимает студента1, студента2,…
Вариант 3. Журнал_посещаемости имеет запись про студента1 и курс1.

Все варианты материалистичны, тут просто вопрос: а в вашем бизнес-процессе как используется информация о посещениях? От этого и зависит выбор того или иного варианта.

ООП во многих (а скорее всего во всех) ЯП не позволяет границам объектов пересекаться. А это интересная мысль. Возможно в этом и состоит идея подписки/публикации.
Представим себе ЯП, в котором возможно следующее: переменная «посещение» будет относиться как к классу «студент», так и к классу «курс». Между классами возникло Intersection. У нас может быть 100 студентов и 3 курса. Автоматически выделяется память под каждое пересечение объектов. А обращаться к этой памяти как к объекту, так как пересечение объектов — это набор некоторых полей и методов, то есть тоже объект.
Обращение к пересечению объектов (как я вижу):
intersection(course1, student1).present

А если еще придумать обращение к пересечению классов? Тогда можно класс «журнал посещаемости» определить в два счета. Нет?

Такой подход с пересечениями мог бы избавить от думки, куда должна входить переменная. Да пускай она входит во все объекты, ведь это так на самом деле (материалистично). Но к сожалению, ЯП не позволяют пересечения объектов.(((
Мой опыт показывает, что глаголы должны быть убраны из описания предметных областей.
Они всегда всё портят. Нужно оставить только один глагол: TO BE

Есть студенты.
Есть курсы.
Есть посещения студентом курса. (Это отдельный класс, а если речь про БД, то это будет таблица где будут например данные: id, student_id, course_id, date, time)
То есть нет никакого «Журнала посещаемости», который имеет записи. Есть просто ПОСЕЩЕНИЯ.

И тогда да, у вас у студента будут student.visits, у курса будут course.visits

И это всё прекрасно работает. Если вам хочется пересечения, то это уже отдельный объект/класс/таблица БД и т.д.

И кажется, что это не зависит от языков программирования. Так просто удобно. Если мы говорим про объекты, то надо говорить про их объекты и их свойства.

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

Но к сожалению, ЯП не позволяют пересечения объектов.(((

Называется multiple dispatch, было ещё в lisp образцу 90х. Сейчас есть много где — https://en.m.wikipedia.org/wiki/Multiple_dispatch

Интуитивно похоже на то, что я описал, но…
Я говорю про особенность выделения памяти для пересечений данных, а множественная диспетчеризация — это про функции, которые могут работать с этими пересечениями. То есть мультиметоды могут заполнять пересеченные данные. Или я что-то не понимаю?
Например, в игровом движке — юнит1 и юнит2, мы задаем для них пересечение — переменная булевого типа. False — нет столкновения, True — есть столкновение. Эта переменная имеет одинаковое имя и доступна в обоих объектах, а память используется общая. Все, больше я ничего не предлагаю.
И тут приходят на помощь мультиметоды, которые позволят вычислить столкновение разных игровых объектов. Результат выполнения мультиметода можно записывать в переменную-пересечение.
Мне кажется, это что-то вроде дружественного класса (friend в c++), точнее дружественного поля.)))
В те времена религия утверждала, что планеты движутся по идеальным окружностям, Солнце вращается вокруг Земли, а другие объекты вращаются вокруг Солнца.
Можно подробнее? Не встречал такого. Зашел по ссылке, там написано
Like many philosophers of his era, Kepler had a mystical belief that the circle was the Universe’s perfect shape, and that as a manifestation of Divine order, the planets’ orbits must be circular.
Или под религией в тексте понимается философия?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий