Неизменные функциональные объекты в очень изменяемом домене

Обычно в функциональном программировании у Вас не будет конструкторов стиля C++. Затем даже при том, что концептуально Вы создаете объекты все время, это не означает, что компилятор должен сделать код для выделения нового объекта, потому что это не может влиять на поведение программы. Так как данные неизменны, компилятор видит то, что оценивает, Вы только что определили, и что было передано в Ваши функции.

Затем компилятор может создавать действительно трудный скомпилированный код, который просто вычисляет поля в конкретных объектах, когда они необходимы. То, как хорошо это работает, зависит от качества компилятора, который Вы используете. Однако чистый код функционального программирования говорит компилятор еще много о Вашем коде, чем компилятор C для подобной программы мог принять, и поэтому хороший компилятор может генерировать лучший код, чем, что Вы могли бы ожидать.

Так, по крайней мере, в теории, нет никакой причины, которая будет затронута; реализации функционального программирования могут масштабироваться, точно так же как объектно-ориентированная "куча" выделяют реализации. На практике необходимо понять качество реализации языка, с которой Вы работаете.

MMORPG уже уже пример неизменности. Поскольку игра распространяется по серверам и игровым системам, здесь абсолютно нет центрального объекта «игровой мир». Таким образом, любой объект, который отправляется по проводам, является неизменным & mdash; потому что это не изменяется получателем. Вместо этого новый объект или сообщение отправляется в качестве ответа, если таковой имеется.

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

Например, вы играете в Command & amp; Завоевать. Ваш гигантский танк сидит в режиме готовности, охраняя вашу базу. Ваш противник приближается с легким танком, чтобы исследовать вашу базу. Ваш гигантский танк стреляет и поражает танк противника, нанося урон.

Эта игра довольно проста, поэтому я подозреваю, что многое вычисляется локально, когда это возможно. Предположим, что компьютеры двух игроков изначально синхронизированы с точки зрения состояния игры. Затем ваш противник нажимает, чтобы переместить свой легкий танк в вашу базу. Сообщение (неизменяемое) отправляется вам по проводам. Поскольку алгоритм перемещения танка (вероятно) является детерминированным, ваша копия Command & amp; Завоеватель может перемещать танк противника на экране, обновляя состояние игры (может быть неизменным или изменяемым). Когда легкий танк попадает в зону действия вашего гигантского танка, ваш танк стреляет. На сервере генерируется случайное значение (в этом случае в качестве сервера произвольно выбирается один компьютер), чтобы определить, попал ли выстрел по вашему противнику или нет. Предполагая, что танк был поражен, и обновление танка вашего противника должно быть сделано, только diff & mdash; тот факт, что новый уровень брони танка снизился до 22% & mdash; отправляется по проводам для синхронизации игр двух игроков. Это сообщение является неизменным.

Не имеет значения, является ли объект на компьютере игрока, представляющий танк, изменяемым или неизменным; это может быть реализовано в любом случае. Каждый игрок напрямую не меняет состояние игры других игроков.

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

При разработке функциональной программы важно учитывать, что, как вы утверждаете, неизменяемые объекты будут иметь некоторые накладные расходы. Также важно помнить, что, если объекты в вашей MMORPG-программе будут неизменными, это по своей природе будет более масштабируемым. Таким образом, первоначальные инвестиции в оборудование могут быть выше, но в будущем, по мере расширения, вы сможете масштабироваться до своей базы игроков.

Еще одна важная вещь, которую следует учитывать, это то, что сейчас самые мощные машины имеют 6 ядер на процессор. Рассмотрим машину с двумя процессорами по 6 ядер. Одно из этих 12 ядер может выполнять сборку мусора, поэтому накладные расходы на снос большого количества объектов могут быть компенсированы за счет того, что приложение легко масштабируется до остальных 11 ядер.

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

Не думайте о создании объекта на проводном уровне. Например, оптимизированное время выполнения для функционального языка, вероятно, будет в состоянии "обмануть" когда дело доходит до замены объекта, и фактический делают мутацию существующей структуры, если это знает, что ничто не сошлется на оригинал, и новый заменяет его полностью. Думайте об Оптимизации хвостовой рекурсии, но примененный к объектному состоянию.

Сегодня я нашел блог, в котором ТОЧНО рассматриваются вопросы, которые я поднял в этом посте:

http://prog21.dadgum.com/23.html

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

у Eric Lippert есть немного интересные сообщения по теме неизменности, и они - вполне интересное чтение.