Какие наборы паттернов применяются при написание апи чаще всего?
Я всегда применяю API как MVC паттерн, собственно заезженный и гуглибельный, но какой в нем смысл если V- никак не реализовано!??сейчас читая банду четырех все равно не могу сказать что я прям выудил для себя много для построения АПИ.Так же не много читал Паттерны JS. Общее представление о каждом из паттернов-да, смело юзать все таки не увидев напутствия на тостере не могу, так что какие паттерны и в каком контексте мне лучше использовать?Подобный вопрос я уже ранее задавал но все таки конкретики не получил
Тимур Шемсединов: не нажали ответить и я не получил уведомление... Обосрали картинки из гугла со стрелочками. Типа - там все херня! А как сами видите не сказали.
Прочел бегло Вашу статью о mvc.. Давным-давно жил тип, который сказал, что если будите делать как говорю я, то будет Вам счастье. Но нет, мы так не делаем, а некоторые даже выкрутили эти слова так, что мол нас создал один и тот же, что означает слова льющиеся из мох уст, его словами.
Но суть не в том. Вы попытались остановить безумие, которое происходит из-за того, что каждый хочет внести в свое... долбанный форум не могу писать страница не скролится
Я с Вами полностью согласен, что люди уверены что их вариация, которая одна из тысячи, верна. Так же как и Вы уверены в своей вариации. Но почему Вы пытались доказать это придумывая свою версию и тем самым обманывая себя и людей ещё больше? Почему Вы не открыли книгу первоисточник и не прочитали написанное там? Ведь это так просто, есть даже на русском языке.
Тимур Шемсединов: и читая Ваши мысли о каких-то фантастических реинкарнациях модели и слова что mvc это херня, я вспомнил себя. Мне когда-то казалось что ооп не существует и он излишен, а mvc это полная бредятина. И казалось мне это настолько уверенно что я открыто об этом говорил. Но однажды, меня как молнией ударило и я понял смысл и ооп и mvc.
Объяснять мне не хочется, это бы заняло очень много времени, но могло бы положить конец безумию... опять скрол...
Тимур Шемсединов: и могло бы положить конец безумию, но я этого не хочу делать, в плане того что писать. Зачем? Пусть дураки себе лбы расшибают доказывая с соплями и слюнями свои выдуманные идеи. Не нужно писать статьи они уже давно написанны теми кого считают основателями. Единственное что не стоит это читать полудурков, которые ещё язык не выучили но уже блоги ведут. Сейчас таких все больше и больше и виноваты в этом не они а те кто от них это требует.
Вы говорите - невозможно отделить модель... Модель не нужно отделять. Представьте себе слово "приложение". Вот не скин, а именно приложение. Что Вы видите? Ответьте на вопрос - если Вас постричь или перекрасить цвет кожи, Вы станете другим человеком? Даже не так... Если Вас покрасить в коричневый цвет Вы станете игроком NBA? Нет, ведь это скин. Но что же тогда Вы если не представление?
Если Вас девушка ласково позовет назвав каким-нибудь пушистым животным, Вы им станете? А если сосед армянин Вас назовет "орлом" клюв у Вас вырастит? То же нет.
получается что Вы и не контроллер.
Значит Вы МОДЕЛЬ!!! Вы это то самое приложение без контроллера и представления.
А теперь поймите, что Вы будите существовать и функционировать и без краски и клюва.
Так же должно и приложение. Приложение, которое модель, должно функционировать без представления и без контроллера и только тогда оно будет приложением.
А что такое контроллер? Представьте что перед Вами на стенде стоит мотор от балида.
Этот мотор является полностью рабочим. Но чтобы завести его, требуется вмешательство человека. Кнопка которую запускает человек и есть контроллер.
Эта кнопка является частью приложения-модели, так как мотор не может функционировать без этой кнопки. И получается, что контроллер своим существованием не меняет приложение, он не вносит то, что не предусмотрено самим приложением. Он просто этого не может сделать, так как модель не предоставляет такой возможности.
Теперь представьте что у мотора есть метод для наращивания оборотов. Это не может быть просто метод execute(), так как прибавить обороты можно резко, что навязывает передачу значений. Вот теперь контроллер начинает передавать в мотор значение. Но что будет если контроллер передаст значений больше мощности мотора.. Мотор просто проигнорирует это. идите? Контроллер передает, а решение принять ли это значение или нет все равно остается за моделью-приложением.
И возвращаясь к Вашим словам о "невозможности отделения модели от других членов mvc" неверны! Ведь модель-приложение с ними и не сращена!
Приложение-модель, это дудка, которая для своего взоимодействия с пользователем предоставляет публик api, клавиши. И в зависимости от того, кто будет нажимать клавиши человек или осминог дудка не изменится и не станет играть как орган.
И резюмировать можно тем что остальные ответы в книге первоисточнике.
Вот неужели Вам сейчас кажется что mvc это полная херня?
ГЛЕБ ГЛЕБОВ: не понял... api приложения, это чистое модель. Или чистое приложение. Представление не имеет отношения к модели так же как и контроллер. Приложение это модель, модель это приложение. Точка. Она модель или оно приложение может работать и без контроллера и без представление.
представление лишь рисует кнопку чтобы пользователь нажал, к контроллер сообщает о нажатии модели-приложению.
copal, ну удивили, я еще такого потока сознания на Тостере не видел, на Хабре постоянно, а на Тостере - впервые.
1. В первоисточнике тоже написана лажа, потому, что отделять код от данных и модель от логики - это идея противоестественная для фоннеймановской архитектуры вычислительной техники. Весь смысл которой в том, чтобы смешивать данные и код в одной универсальной памяти и обрабатывать код как данные, а данные как код, вперемешку, это очень сильная концепция, хоть и не абсолютная. Но реализовывать противную этому идею на ЭВМ с фоннеймановской архитектурой - это безумие. Выделять представление отдельно - это хорошая идея, будь оно в виде шаблонов, визуальных компонентов или чего другого, но представление можно отделить от модуля. Если отделять представление от клиентского ПО, то выходит GUI, если от сервера, то выходит API. Я за то, чтобы не делать MVC правильно по кошерной поваренной книге, а выбросить его нафиг и делать классическую многослойную архитектуру, которая себя оправдала десятилетиями.
2. Вы поддались очарованию объектно-ориентированного подхода, потому, что он позволяет жонглировать абстракциями и выкручивать из них что угодно, но ООП как подход совершенно не состоятелен, я Вам это говорю, как программист с 20-летним стажем, из которых 15 лет писал на ООП и был счастлив этим, который сам написал объектно-ориентированную СУБД в 1999 году, протокол аналог CORBA для объектного маршалинга по сети, свой формат сериализации и использовал ORM когда об этом подходе еще мало кто слышал вообще. Я Вам скажу, что ООП позволяет занять 100 человек задачей моделирования, которая яйца выеденного не стоит, и они будут вести бесконечные холивары о том, у кого должен быть метод "сесть", у "стула" или у "жопы" или нужно сделать клсса "усаживание", который создается на время этого действия и держит ссылки на экземпляры этих двух, или нужно сделать специальные абстрактные интерфейсы "усаживаемое" и "жоповместилище", которые будут соответственно реализованы у обоих классов, а третий будет с пеной у рта доказывать, что модель должна быть анемичной (без методов), а все действия нужно вынести в универсальный контроллер "мирСтульевИЖоп", который хостает все порожденные в нем объекты и оживляет их.
3. В статье habrahabr.ru/post/204958 я описываю старый метод, который был до всего этого грехопадения, метод слоеной архитектуры. Еще раз говорю, что представление отделять хорошо (шаблоны, gui) и это не противоречит этому подходу.
4. Вы скажете, что так можно отказаться от всего удобного и действительно прийти к процедурному программированию, а это каменный век. Но модульное программирование, которое является развитием процедурного до сих пор не устарело и имеет приличный запас прочности, но у него конечно уровень абстрактности слишком низкий, чтобы писать прикладной код, это я согласен. Так есть же реактивное программирование, функциональное и метапрограммирование. На этих трех концепциях я и пишу сейчас весь свой код. Вот тут пару статей: habrahabr.ru/post/137446 и habrahabr.ru/post/227753
В первоисточнике тоже написана лажа, потому, что отделять код от данных и модель от логики - это идея противоестественная для фоннеймановской архитектуры вычислительной техники.
Переубеждать человека с таким большим стажем, по этому начну с далека. Что Вы имеете ввиду под отделение модели от логики? Ведь я специально повторял, что модель === приложение, ну и можно же продолжить дальше и получить приложение === логика. И не заметить этого просто невозможно. Получается что Вы подразумеваете что-то другое. Что?
copal: Модель !== приложение. Модель (а именно информационная модель) - это упрощенное представление реального объекта. Есть физические модели, математические. Приложение - это совсем другое, приложение может вообще не быть моделью чего-то. Например, архиватор RAR - это модель чего? Браузер Chrome - это модель чего?
Тимур Шемсединов: я всегда говорю о первоисточнике, по этому когда я буду говорить о своем mvc, то буду подразумевать первоисточник. Так вот, когда я говорил о мадели равной приложению, то имел ввиду ту модель, которая из mvc.
Но если я правильно понял, то Вы говорите о модели, которая задает поведение объекта, а не о модели из mvc? Я очень люблю тему обсуждать тему архитектуры и искренне пытаюсь понять Ваши слова, но не получается.
Но тут даже вот как.. Модель и только модель (из mvc) содержит всю бизнес логику приложения. Создав объект модели, мы имеем на руках информационную модель так же содержащую всю бизнес логику приложения. Вы об этом?
Вы говорите так, будто о моделях, которые являются миниатюрами существующих в нашем мире объектов. Типа - машина - сувенирная машина...
copal: Я говорю о понятии модель в его научно-техническом смысле, так как его должен понимать инженер, в том числе и инженер-программист. Информационная модель содержит данные и логику моделируемой предметной области, но это еще не все данные логика приложения, приложение это граздо шире. Например, интерфейс пользователя протоколов передачи данных, форматов сепиализации и служебных функций приложения ни как не относится к предметной области.
Тимур Шемсединов: тогда получается, что создавая приложение "человек", я вписываюсь в инженерную модель и слова "модель===приложение===логика" не вызовут недоумение.
Но я кажется понимаю к чему Вы. Вы не можете вписать в моделируемую среду, грубо говоря, загрузку, отправку... Да? Если да, то это делать и не нужно, это к mvc отношения не имеет.
Но если нет, то я тогда сдаюсь и признаю что Вас не понимаю. Модель человека, это нормально, но модель браузера нет. Но браузер не чем не отличается от модели машины, которые моделируют те же инженеры. И получается что Вы говорите - приложение "мир" это неправильно, ведь человеки и машины и природные явления это разные предметные области. Да, разные! Но они все реализуют свои модели. Вот у меня есть игра построенная на парадигме mvc. В ней есть персонаж, он тоже реализован на парадигме mvc, но загружен в мир. Вот загрузчик это не mvc. mvc без разницы что и от куда берется. То есть, mvc в mvc это есть мир, а по отдельности это разные приложения - "человек", "мир". Что здесь противоречит инженерным моделям?
А передача данных по сети это не логика приложения и я с Вами согласен. И даже замечу, что все бредни с mvc вызваны тем, что непонимающие пытаются сделать из mvc бога, которым занимается прям всем-всем и загрузкой и хранением данных. И вот когда они все это пытаются связать при помощи mvc и начинаются рождаться парадигмы-уродцы.
Ни кто не пишет приложение "человек", приложение может быть "информационная система учета человеков в больнице" или "система обучения человеков пилотированию самолетов" или "экспертная система социологических исследований на человеках". И "человек" живет внутри этих информационных систем. При этом "человек" - это не модель, это класс. Модель это вся совокупность классов, объектов, прототипов, структур данных, событий. Вы во всех сообщениях, когда хотите сказать ООП, говорите mvc, такое впечатление, то ООП без mvc не существует. Но mvc - это всего один из паттернов в рамках парадигмы программирования ООП, а кроме ООП есть и другие парадигмы, и эти парадигмы пораждают другие модели. Например, реактивное программирование порождает событийную модель предметной области, а функциональное программирование пораждает функциональную модель, могут быть их гибриды, это все разные модели. Вы даже ООП мыслите из рамок одного паттерна, если так смотреть, то не видно общей картины и кажется, что mvc подходит как нельзя лучше для всего-всего. Но в каких-то слечаях модель ориентированных графов, в которых вершина это состояние, а дуга это переход, может быть гораздо эффективнее ООП, не говоря уже про mvc. Идея моделей в том, что мы берем отдельный аспект моделируемой предметной области, реализуем программно не все, а только упрощенное отображение, представление, которого хватает для решения прикладной задачи.
Кроме моделей в приложениях от 10% до 90% может быть такого функционала, который даже не относится к моделям, например, операционная система вообще почти лишена моделей, все задачи, связанные с файловой системой, процессами, сетью, драйверами, окнами, выделением памяти, переключением контекстов - это все служебные задачи. Ладно, операционная система это отдельный случай, вот браузер - к нам ближе, и в нем, опять таки, нет ни каких моделей, браузер не модель "мира", в мире нет страниц, дерева DOM, HTTP-запросов, рендеринга, стилей, джаваскрипта, кукизов, все это служебные понятия. Теперь пример из прикладных приложений, в них тоже очень много не относящегося к моделям: логировние, драйвера доступа к базам данных, библиотеки шифрования и обработки изображений, математические библиотеки, доступ к API операционной системы, все, что связано с сериализацией/десериализацией и работой с форматами данных (JSON, XML, YAML, CSV, UTF-8, SVG, CSS, PDF и т.д.), все что связано с графическим интерфейсом (окна и компоненты, шаблоны, шрифты, стили, векторная графика, весь рендеринг), реализации прикладных протоколов HTTP/HTTPS, SMTP, IMAP/POP3, RDP, SSH и т.д., конфигурация (загрузка конфигурации, инициализация приложений из конфигурации и т.д.), задачи безопасности, шины событий, обработка ошибок, архивирование и распаковка, видео- и аудио-кодирование, захват видео и звука, обработка текста (синтаксический анализ, парсинг, регулярные выражения), я могу перечислять это еще 3 страницы. Задач, которые не укладываются ни в паттерн mvc, ни в парадигму ООП и даже вообще в концепцию моделирования, на порядок больше, чем тех, что укладываются.
Вы совершенно правы, что уродцы рождаются от того, что часто в коллективах нет архитекторов и постановщиков заданий, нет людей имеющих достаточный опыт, а задачу начинают решать после прочтения 2-3 статеек сомнительной ценности. Вот и получается, что применяют не соответствующие инструменты, не адекватные задачам.
Тимур Шемсединов: про приложение "человеков" я сказал лишь из-за того, что Вы привили модель браузера, как нереальную для инженера. В мире не рендера, в мире нет кукизов...
Но ведь в мире и машин и заводов нет, но их инженеры проектируют.
И да, человек, это класс в ООП, но в мире mvс... Давайте так - у меня есть приложение, которое показывает как за "кем-то" гонятся "кто-то", то есть приложение "погоня". Это приложение и как я раньше уже говорил, это так же и модель. Теперь представим что я вместо за кем гонятся вставляю "человека", а вместо догоняющих человеков-бандитов. Дабавил их я не в приложение, а в вью. Изменилось приложение? Нет! Теперь я вместо добавляю тролля за котором гонятся эльфы. Приложение изменилось? нет! Но почему? Потому что в данном случаи это просто, как Вы говорите, классы. Они не входят в приложение-модель и в рамках mvc мы вообще о них не говорим упоминая модель.
А теперь представьте что у меня приложение "погоня со стрельбой". Теперь у меня есть те кто догоняет и тот кого догоняют. Когда догоняющие приближаются к догоняемому, то они стреляют и у него отнимается жизнь. Вот с этого момента мое приложение кардинально начинает отличатся от первого, ведь в него добавился убегающий. От того каким именно будет убегающий, зависит исход приложения-приложения. Если у убегающего на спине будет щит, то он сможет убегать дольше, что увеличит шанс на победу. то есть, в mvc, а именно в модель-приложение вводится модель-убегающего.
Теперь говоря о убегающем я не говорю о классе, я говорю о модели убегающего.
Понимаете? Когда я говорю о моделях, я не говорю о классах из ооп, я говорю о моделях в рамках mvc. И вот как раз то что я называю моделью и является Вашей моделью в плане инженерии. Это лишь характеристики и прочие данные которые нужны инженеру, чтобы внедрить эту модель, модель убегающего, в модель приложения "погоня со стрельбой", ведь как я говорил раньше, приложение должно работать и без контроллера с представлением.
И далее... Вы похожи на бульдозер! Вы пытаетесь все на свете сгребсти в одну кучу и сказать - вот эту каку mvc точно не разрулит. Да, ведь оно для другого. Таски системы, работу интерпритаторов и прочее отношение к mvc не имеют. Это отдельные части "чего-то", возможно тех же моделей. Но я на тему устройства самой машины не буду говорить, так как я не знаю как она устроена. Я говорю о mvc при помощи которого строят приложения, а не винты в микросхемы заворачивают. Но если взять браузерный интерпритатор, то можно сказать что он по mvc.
И могу лишь добавить, что Вы не правы, говоря "адач, которые не укладываются ни в паттерн mvc, ни в парадигму ООП и даже вообще в концепцию моделирования, на порядок больше, чем тех, что укладываются."
Если Вы хотите все это закрепить словами, что это правда, ведь они написаны на языке не реализующую ооп парадигму, то это стоже самое что утверждать что корова не умеет летать потому что у птиц нет вымя...
И я так и не смог услышать о том, что mvc неправильное. Все что сказали, это "модель не та модель", но на деле она та самая.. И говорить о mvc и ооп в рамках языка который его не реализуют - глупо. А утверждая что на не ооп языке можно реализовать парадигму mvc равно тому, что признать что эти языки куда становятся куда приятнее если их использовать "как ооп языки".
Как говорит Жванецкий, «Давайте спорить о вкусе устриц с теми кто их ел». Из Ваших рассуждений очевидно, что другого опыта, кроме паттерна mvc у Вас нет. Весь мир Вы видите только через mvc. И модель для Вас - это модель из паттерна mvc и браузер по mvc построен и про ООП Вы знаете только отдаленные слухи из публикаций про mvc. Про другие парадигмы мало что слышали, как устроены браузеры, СУБД, операционные системы, компиляторы, память, процессор и вообще вычислительная техника, не имеете понятия, достаточного для спора. Из задач приводите примеры или совсем учебные или из области компьютерных игр, это очень маленький кругозор для серьезных обобщений. Вы не владеете даже общепринятой терминологией для инженерии, для программирования, для ООП и для архитектуры информационных систем. В таких условиях спорить с Вами совершенно бесполезно. Рекомендую почитать базовую литературу по программированию, Дэйкстру, Вирта, Кнута, Буча. Когда будете иметь представление, что такое архитектура фоннеймана и в чем особенность конечных автоматов (мура и мили), парадигму автоматного программирования, парадигму обобщенного программирования, парадигму реактивного программирования, парадигму функционального программирования, парадигму реактивного программирования, парадигму прототипного программирования и будете ее отличать от объектно-ориентированного и объектно-базированного программирования. По моделям данных пощупаете СУБД реляционные, графовые, документные, объектные и иерархические. Наберете хоть 5-7 лет практики, десяток языков программирования, сделаете обобщения, а пока, и обобщать-то Вам нечего. И почитайте прямо сейчас мнения супер-бизонов про ООП, которые поопытнее меня будут: blogerator.ru/page/oop_why-objects-have-failed Так что, это не только мое уникальное такое мнение сложилось, там под статьей есть ссылки и дополнения, все достаточно аргументировано.
Тимур Шемсединов: Да, я действительно не имею двадцатилетнего стажа, и не знаю парадигм до ооп'шного времени, но.. Но я не считаю что дедушка может упрекать меня в использовании 3D фрезерного станка, аргументируя это отсутствием познаний в лобзиках и молоточков. Про ооп я могу очень долго разговаривать так же как и о mvc, но с оппонентом который может либо выслушать, либо научить, а не слушать упреки связанные с тем, что раньше информации было так мало, что люди с двадцатилетним стажем сравнялись со студентами. Да и не считаю я что нужно обладать какими-то запредельными знаниями чтобы обсуждать то, что похоже на детский конструктор лего.
С другими не mv* парадигмами я и вправду не знаком, но не думаю, что мне бы понравились парадигмы которые все смешивают... Да таких наверное и нет. Рекомендуемые Вами книги обязательно почитаю, но боюсь там уже не будет того, о чем бы я не знал.
И учтите, когда я выучу десяток языков, то при первой встрече уделаю Вас и напомню что уделал бы ещё сейчас. Сейчас мне и вправду нечего сопоставить с Вашим стажем и не исключаю, что окажись на Вашем месте не повел бы себя так же. И спасибо за информацию, которая жадно прикует мое внимание к тем моментам, которые бы я мог и пропустить если бы этот разговор не состоялся.
Я не стараюсь Вас как-то обидеть, просто пытаюсь показать, что мир не сошелся клином на mvc и это не самый передний фронт и не самая последняя технология. Мир намного разнообразнее, а функциональное и реактивное программирование это не прошлый век, исследования и разработки в этом направлении более современные, чем разработки в ООП. Почитайте пожалуйста статьи про facebook.github.io/react и про Web-components webcomponents.org Вообще, компонентный подход гораздо красивее, чем mvc, и веб наконец движется в этом направлении от ереси шаблонизаторов и нелепого разделения html, css и javascriot. Компонент - это все вместе, и верстка и стили и поведение, слепленные туго в визуальные контролы, как кнопка, список, дерево, меню и т.д. и уже дальше склеиваемые в композитные контролы. Сравните это с ересью ангулара и будет счастье, а этот подход использовался еще Delphi и сейчас живет в C# и Java. Только вот в вебе сразу не удалось его реализовать из-за войны браузеров и стандартов, которая до сего дня держала весь веб в состоянии дикости глухого средневековья. Почитайте про веб-компоненты и реакт на хабре. Нужно следить за передним краем технологий. habrahabr.ru/search/?q=%5Bweb%20components%5D&targ... и тут habrahabr.ru/hub/ReactJS И посмотрете habrahabr.ru/post/251835
Тимур Шемсединов: да я слежу за всеми новостями, но время все опробовать нет. И я хорошо понимаю о чем Вы, когда говорите что html, css и js должны слиться. Я очень хорошо, даже больше чем хорошо знаю flash, где единство выражено лучше чем в java или c#. И я тоже за это слияние, но будет ли оно и когда, какими силами.
И angular для меня и есть почти ересь, точно так же как и ror и прочие фраймвоорки, которые реализуют mvc, но по какой-то странной концепции. По этому я и ввязываюсь в обсуждение, чтобы доказать людям одну простую истину - если Вы говорите что Ваш фраймворк реализует mvc то пусть он его реализует так, как это было описано в первоисточнике, все остальное это все что угодно но не mvc.
И Вы мне в пример приводите компоненты, которые для меня, как человека из gamedev слишком простые. Это обычного html,css, js девелопера можно удивить созданием компонентов, а то от куда пришел я создавать компоненты, это ещё даже не зародышное состояние. И когда я разговариваю о mvc то не думаю о компонентах, я думаю о фраймворках и игровых движках, в которые связать в легко поддерживаемую игру без mvc, я бы сказал, невозможно.
Тимур Шемсединов: а парадигма конечные автоматы и паттерн конечные автоматы это одно и тоже? А модель актеров это типа объект актер который диспатчит события?
Парадигма программирования называется автоматное программирование, а паттерна там два (автомат мура и автомат мили), это когда есть определенный набор состояний системы и заданы правила переходов из состояния в состояние. Правила могут быть заданы как логические или математические выражения, как функции, как декларативные конструкции, но суть в том, что мы имеем сеть (граф), например https://ru.wikipedia.org/wiki/Сети_Петри или есть еще Р-модели (которые разрабатывает, например, проф. Вельбицкий) и есть дуги переходов. Автомат может одновременно находиться в одном состоянии, и переходить по той дуге, в которой срабатывают условия в другое состояние. Игровой мир строится из множества автоматов.
Модель акторов это когда процессы или объекты не взаимодействуют друг с другом напрямую, а могут посылать/получать в/из шины событий сообщения. Это позволяет создавать, например, игровые миры, которые обсчитываются сотнями и тысячами серверов. Вообще акторы используются не только в играх, а это одна из базовых технологий для параллельных вычислений.
Акторы – это набор практик, методология разработки, архитектурный паттерн, маркетинговый ход?
В моем университетском курсе, как и у многих, понятие вычислимости определялось через машины Тьюринга и Поста. У машины есть состояние – совокупность значений всех ячеек ленты. Процесс вычислений представляет собой последовательность шагов машины, каждый из которых меняет ее состояние. Каждый шаг машины – выполнение одного атомарного неделимого действия (операции). Далее буду называть это традиционной моделью вычислений.
Такая трактовка вычислений приводит к понятию глобального времени, когда в один и тот же момент времени может выполняться одна и только одна атомарная операция. Это свойство существенным образом используется для доказательства свойств различных примитивов синхронизации в случае многопоточного программирования на однопроцессорных машинах, например, в книге Грегори Р. Эндрюс Основы многопоточного, параллельного и распределенного программирования.
Для многопроцессорных машин или распределенных систем требование глобального времени, в общем случае, неприемлемо. Следовательно, необходимо обобщить понятие вычислимости на случай параллельных вычислений. Одним из таких обобщений и является модель акторов.
После прочтения цитируемого выше из этой статьи на хабреМодели акторов 40 лет! я понял что мне это напоминает.
Это совокупность паттернов Команда, Спецификация ну и что-то должно быть от EventDispetcher или GlobalDispatсher, Observer ну или в край Signal, это мне кажется не важно, кому как больше нравится тот так и сделает. И если это так, то я эту парадигму знаю. Она типа создает таски но не просто последовательность, а последовательность с условием (if, elese, видел даже как цикл while прикручивали в synс). И когда один таск выполняется то шлет событие-уведомление и в зависимости от результаты выполнения будет произведено следующие действие. Ведь я не ошибся? Если не ошибаюсь, то я очень плотно использую "это" и даже не представляю как без этого можно писать код. Но вот что странно, что я сейчас ещё раз прочитал Ваше определение о модели актеров и оно полностью противоречит статье, в которой сказано -
Такая трактовка вычислений приводит к понятию глобального времени, когда в один и тот же момент времени может выполняться одна и только одна атомарная операция.
А у Вас -
Вообще акторы используются не только в играх, а это одна из базовых технологий для параллельных вычислений.
copal: в первой цитате говорится об автоматах во второй про модель акторов. Это разные вещи, даже противоположные в каком-то смысле. Автоматы работают пошагово, выполняют одну операцию за квант времени, а актоары работают параллельно, группа акторов может исполнять параллельно разные действия, хотя поток событий, приводящие их движение, может быть один общий.
Простой
