Comments 6
Вариант 1. Студент1 присутствует на курсе1.
Вариант 2. Курс1 принимает студента1, студента2,…
Вариант 3. Журнал_посещаемости имеет запись про студента1 и курс1.
Все варианты материалистичны, тут просто вопрос: а в вашем бизнес-процессе как используется информация о посещениях? От этого и зависит выбор того или иного варианта.
ООП во многих (а скорее всего во всех) ЯП не позволяет границам объектов пересекаться. А это интересная мысль. Возможно в этом и состоит идея подписки/публикации.
Представим себе ЯП, в котором возможно следующее: переменная «посещение» будет относиться как к классу «студент», так и к классу «курс». Между классами возникло Intersection. У нас может быть 100 студентов и 3 курса. Автоматически выделяется память под каждое пересечение объектов. А обращаться к этой памяти как к объекту, так как пересечение объектов — это набор некоторых полей и методов, то есть тоже объект.
Обращение к пересечению объектов (как я вижу):
intersection(course1, student1).present
А если еще придумать обращение к пересечению классов? Тогда можно класс «журнал посещаемости» определить в два счета. Нет?
Такой подход с пересечениями мог бы избавить от думки, куда должна входить переменная. Да пускай она входит во все объекты, ведь это так на самом деле (материалистично). Но к сожалению, ЯП не позволяют пересечения объектов.(((
Вариант 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
И это всё прекрасно работает. Если вам хочется пересечения, то это уже отдельный объект/класс/таблица БД и т.д.
И кажется, что это не зависит от языков программирования. Так просто удобно. Если мы говорим про объекты, то надо говорить про их объекты и их свойства.
Они всегда всё портят. Нужно оставить только один глагол: 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++), точнее дружественного поля.)))
Я говорю про особенность выделения памяти для пересечений данных, а множественная диспетчеризация — это про функции, которые могут работать с этими пересечениями. То есть мультиметоды могут заполнять пересеченные данные. Или я что-то не понимаю?
Например, в игровом движке — юнит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.Или под религией в тексте понимается философия?
Sign up to leave a comment.
Когда объектов не достаточно