LINUX.ORG.RU

Как сделать объектную модель для ситуации «мама мыла раму»?

 


0

3

Дополнительные требования:
1) мам много;
2) мамы являются подмножеством гуманоидов;
3) рам много;
4) вымытая рама приносит гуманоидам счастье;
5) со временем вымытая рама постепенно становится невымытой;
6) в зависимости от внешних условий, рамы становятся невымытыми за разное время загрязнения
7) у разных рам разные размеры и нормативы на время отмывки;
8) мытьё рам занимает время;
9) перемещение между рамами занимает время
10) кроме мытья рам, мамы могут отдыхать
11) фигня случается

модель должна быть событийной, т.е. время от времени происходят события
(разная фигня типа
«рама загрязнилась»,
«мама переместилась к раме»,
«мама вымыла раму»,
«вымытая рама нанесла счастье гуманоидам»)

Проектируемое/предлагаемое решение должно позволять менять текущее состояние
(загрязнять указанные рамы принудительно, направлять мам на отмывку указанных рам)
и выяснять текущее состояние
(количество полученного счастья от сотворения мира)

одни неверные предположения, ещё и баг с бесконечно увеличивающимся счастьем.
требования — идиотские. модель — не должна. мамы в этом описании могут перемещаться в нигде.

Как сделать объектную модель для

перестать быть тобой.

system-root ★★★★★ ()

С началом нового учебного года!!!!!!11

Рама - объект. Дальше - сам.

Deleted ()
Последнее исправление: rht (всего исправлений: 1 )

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

Неверно, в контексте задачи, мамы - реализации интерфейса «мойщик рам».

Как сделать...

Непонятно, что именно непонятно.

no-such-file ★★★★★ ()

Тебе что надо? Готовое решение? У меня есть полуготовое на js (действия над объектами, выяснение, какие действия может совершить объект над другими, объявление объектов, действий, области досягаемости, зачатки скриптового ии). Надо только время допилить.

crutch_master ★★★★★ ()
Последнее исправление: crutch_master (всего исправлений: 1 )
Ответ на: комментарий от no-such-file

Непонятно, что именно непонятно.

Интересует решительно всё, начиная от обеспечения многопоточности, до интеграции с питоном

Einstok_Fair ★★☆ ()
Ответ на: комментарий от Einstok_Fair

начиная от обеспечения многопоточности, до интеграции с питоном

Тогда нужно было писать в Job.

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

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

Неверно, в контексте задачи, мамы - реализации интерфейса «мойщик рам».

Человек (гуманоид) создан для счастья, как птица для полёта. Мамы имеют право на счастье. Значит они не только мойщики рам.

Einstok_Fair ★★☆ ()
Последнее исправление: Einstok_Fair (всего исправлений: 1 )

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

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

King_Carlo ★★★★★ ()
Последнее исправление: King_Carlo (всего исправлений: 1 )
Ответ на: комментарий от Einstok_Fair

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

начни с проектирования лимбической системы https://doctor-narcolog.livejournal.com/6928.html

anonymous ()

в модели нехватает как минимум «дитя», иначе там не мама по определению; и взаимодействия сего дитя с другими объектами.

Например обнулить мамино-рамино щастье путём разбития стекла, иначе счатье overflow :-)

MKuznetsov ★★★★★ ()
Ответ на: комментарий от MKuznetsov

нужно ввести в мобель понятие «дофаминовое выгорание», тогда и без битых стёкол можно обойтись

anonymous ()
Ответ на: комментарий от MKuznetsov

в модели нехватает как минимум «дитя»

почему не хватает? Я же написал, что мамы это подмножество человеков. Значит есть другие человеки. Возможно часть из них дети (но это деталь вне скопа проектирования).

взаимодействия сего дитя с другими объектами

Есть внешние воздействия (я ж написал, что можно «загрязнять указанные рамы принудительно»). Возможно, внешняя программа будет предполагать, что такие действия проделывают именно дети. Но это опять таки деталь вне скопа этой конкретной библиотеки.

обнулить мамино-рамино щастье ..., иначе счатье overflow

Может меня overflow интересует с точки зрения проектных решений по борьбе с ним. Обнуление - не единственное возможное решение. Почему этим должна заниматься библиотека, а не вызывающий код? В общем, считаю, что вне скопа.

Einstok_Fair ★★☆ ()
Ответ на: комментарий от Einstok_Fair

почему не хватает? Я же написал, что мамы это подмножество человеков. Значит есть другие человеки. Возможно часть из них дети (но это деталь вне скопа проектирования).

потому что «мама» - экземпляр «человеков», женского пола, с интерфейсом фабрики и как минимум одним порождённым объектом :-)

MKuznetsov ★★★★★ ()
Последнее исправление: MKuznetsov (всего исправлений: 1 )
Ответ на: комментарий от MKuznetsov

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

Einstok_Fair ★★☆ ()
Ответ на: комментарий от system-root

могут перемещаться в нигде.

в междурамном пространстве

Представим рамы как точки. Построем диаграмму Вороного. На диаграмме Вороного области Лагранжа сделаем ненулевой толщины. Это и будет междурамное пространство (предположительно люди могут находится в нём до перемещения к своей первой раме).

Einstok_Fair ★★☆ ()
Последнее исправление: Einstok_Fair (всего исправлений: 2 )
Ответ на: комментарий от Einstok_Fair

Нет. В контексте задачи мама - реализация интерфейса мойщик рамы. Что мама делает вне задачи нас не интересует.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

процесс генерации и распределения счастья недостаточно хорошо прописан в требованиях. Его (проектировщику) нужно доопределить.

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

Сосед Вася отличается от мамы тем, что он не моет рамы, хотя и получает счастье от вымытой рамы.

Einstok_Fair ★★☆ ()
Ответ на: комментарий от Einstok_Fair

Тогда мама реализация интерфейса «мойщик рам», а сосед — реализация интерфейса «пользователь мытых рам» или ещё какого-то.

peregrine ★★★★★ ()
Ответ на: комментарий от peregrine

«пользователь мытых рам» => «получатель счастья» => «человек»

Einstok_Fair ★★☆ ()
Ответ на: комментарий от crutch_master

Что именно ты там собрался многопоточить?

Мам около пяти миллиардов. Сколько рам - неизвестно. Но точно понятно, что нагрузка на память низкой не будет. Радует хотя бы то, что счастье рамы наносят локально.

Это значит, нужно принять архитектурное решение и ввести объекты
«хост» (компьютер, который отвечает за моделирование конкретной рамы и связанных мам/людей),
«гвест» (пользователь библиотеки, который желает управлять рамами и мами)

Гвестов может быть много, однако наблюдают они не за всеми объектами модели.

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

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

Einstok_Fair ★★☆ ()

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

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1 )

Звучит так, что нужна очередь событий, и интерфейс у рамы, за который мама его моет. Именно так я бы и сделал. Но я не настоящий погромист.

Shadow ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

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

Shadow ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Одна очередь. Загрязнившаяся рама кидает туда запрос на мытьё, первая случайная свободная мама, заглянувшая в очередь, берёт из очереди ссылку на интерфейс рамы и моет её.

Shadow ★★★★★ ()
Ответ на: комментарий от Shadow

это принуждение мам к труду. Рама отправляет приложению сообщение о том, что она загрязнилась. Приложение принимает решение кого куда и как направлять (возможно используя для этого очередь, но это уже не проблемы библиотеки)

Einstok_Fair ★★☆ ()
Ответ на: комментарий от Valman_old

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

Einstok_Fair ★★☆ ()

Зачем здесь ваще «объекты»? Похоже на дискретно-событийное моделирование. Что нужно-то сделать? Определить набор правил? Оптимизировать этот набор правил по заданным параметрам? Тогда еще Монте-Карло и какой-нибудь метод целочисленной оптимизации в дополнение к имитационному моделированию.

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 1 )
Ответ на: комментарий от dave

Зачем здесь ваще «объекты»?

Они здесь не «зачем», а «почему». Потому что субъект, действие и объект (Мама мыла раму). Если количество видов субъектов, количество видов действий и количество видов объектов увеличить, то можно будет смоделировать более сложный процесс.

Что нужно-то сделать?

Мне нужно понять, как писать приложения.

Einstok_Fair ★★☆ ()
Ответ на: комментарий от Einstok_Fair

gc не может быть нормальным. его суть - быть костылём для программеров-калек.

anonymous ()
Ответ на: комментарий от Einstok_Fair

GC не нужен, многопоточность, в общем, не нужна. Бери rabbitmq и что угодно. Делай интерфейсы: список рам, мам, мыть раму, передать мам/рам хосту, передать/получить список хостов. Если хорошо упороться, можно взять js и передавать параметры и поведение объектов прямо в рантайм без пердолинга с пересборкой хоста.

crutch_master ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Мне нужно понять, как писать приложения.

Для начала тебе надо понять, как НЕ надо писать приложения. Это просто. Напиши как угодно, а чём чём угодно.

crutch_master ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Кода у меня для таких масштабов нет, хотя, если немного переделать..

crutch_master ★★★★★ ()
Ответ на: комментарий от Einstok_Fair

Даже в Симуле за имитационное моделирование отвечали, скорее, сопрограммы, чем объекты, но раз ты задумал использовать «объекты», то ради бога.

Кстати, насчет rust. Там нет классического ООП, которого ты ждешь, а именно, нет наследования реализации, но есть инкапсуляция, есть наследование интерфейсов и можно сварганить полиморфизм ad-hoc. Там почти такая же модель работы с объектами как в haskell. Названия только немного отличаются: module -> mod, type class -> trait, polymophism -> generics, class constraint -> generic constraint, record -> struct, sum type -> enum type, а также самая вишенка: existential quantification -> trait object. Только и там, и там хорошая штука. Можно брать!

dave ★★★★★ ()
Последнее исправление: dave (всего исправлений: 2 )
Ответ на: комментарий от Einstok_Fair

Наличие рам не подразумевает наличия стёкол. Может там деревянные ставни.

или рама от камаза.

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

Rastafarra ★★★★ ()

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

Deleted ()
1 декабря 2018 г.

Допустим, что рама хранит два массива:
- массив тех, кто находится рядом с этой рамой
- массив тех, кто эту раму в данный момент моет

Так как рама не определяет смерть людей, то это массивы типа GArray, и содержат они в себе GWeakRef.

Допустим, какая-то нить решила взять и напечатать имена мам, которые в данный момент моют эту раму. Это вообще сильно похоже на транзакцию - получить ссылки на объекты мам (и, вероятно, увеличить их refcount-ы). Затем вывести имена на печать. Затем отпустить ссылки на мам.
Наращивать refcount для мам обязательно, потому что иначе при выводе имён мам могут возникнуть проблемы (объект может быть удалён в другом потоке).

Как конкретно получить из GWeakRef указатель с одновременным наращиванием refcount? g_weak_ref_get

Настораживает то, что операция получения списка мам неатомарная. Хорошо бы ещё иметь возможность блокировать изменение списка мам на время снятия копии списка.

Как получить из массива GWeakRef массив GPtrArray в одно действие с блокировкой других операций с исходным массивом на время выполнения операции копирования массива?

В общем, отсутствие учебного примера расстраивает.

Einstok_Fair ★★☆ ()
Последнее исправление: Einstok_Fair (всего исправлений: 4 )
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.