Что такое шаблон проектирования «Все исправить»?

В этой статье Стивена Фиггинса, написанной в 2003 году на linuxdevcenter.com , BitTorrent Брэма Коэна описывается как использование шаблона проектирования «Исправить все».

Менее распространенный подход, который затрудняет понимание BitTorrent, но заслуживает изучения, - это использование иденпотентности Коэном. Процесс идемпотентен, если его применять более одного раза, и не вызывает дальнейших изменений. Коэн говорит, что он использует шаблон проектирования, который он называет «Исправить все», функцию, которая может реагировать на ряд изменений, даже не замечая, что все это может изменить. Он объясняет: «Вы замечаете произошедшее событие, а затем вызываете функцию« исправить все », написанную очень идемпотентно, и просто очищаете все, что может происходить, и пересчитываете все это с нуля». Хотя идемпотентность облегчает некоторые сложные вычисления, она делает вещи немного запутанными. Не всегда ясно, что вызов изменит, если что-нибудь. Вам не нужно знать заранее. Вы можете вызвать функцию,

Это звучит довольно мило на первый взгляд.

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

Я не могу сказать, что использовал это раньше. Я также не могу найти источник его приложения в Интернете (но я нашел этот, который утверждает, что основан на нем.). Кроме того, я не могу найти ссылку на нее за пределами этой статьи (и я считаю, что мое google-fu довольно неплохо), но я нашел запись о «Идемпотентной способности» на SOApatterns.org .

Эта идея более известна под другим именем?

Что такое шаблон проектирования «Все исправить»? Каковы его плюсы и минусы?

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

1. Напишите отдельный обработчик для каждого элемента управления, который отвечает на события в этом элементе управления и обновляет другие элементы управления по мере необходимости.

2. Напишите один обработчик, который просматривает состояние всех элементов управления на странице и просто исправляет все .

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

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

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

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

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

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

Я думаю, что статья немного устарела, потому что, когда я ее читаю, это вовсе не неортодоксальная или новая идея. Эта идея представлена ​​в виде отдельного шаблона, когда она на самом деле является простой реализацией Observer. Вспоминая то, что я делал в то время, я помню, как работал над логикой, чтобы сидеть за довольно сложным интерфейсом с множеством различных панелей с данными, которые были взаимозависимы. Пользователь может изменить значения и / или запустить процедуру оптимизации, и на основе этих действий генерируются события, которые пользовательский интерфейс будет прослушивать и обновлять по мере необходимости. Во время разработки был ряд проблем, когда некоторые панели не обновлялись, когда должны были. Исправление (оставаясь в дизайне) состояло в том, чтобы генерировать события из других событий. В конце концов, к тому времени, когда все заработало, почти каждое изменение привело к обновлению всех панелей. Вся сложность попытки выделить нужную панель для обновления была напрасной. И все равно это не имело значения. Это была преждевременная оптимизация. Я бы сэкономил массу времени и усилий, просто сложив все это в одно событие, которое обновило бы все.

Существуют бесчисленные системы, разработанные для «все исправить» или «обновить все». Подумайте обо всех интерфейсах CRUD, которые добавляют / обновляют строку, а затем запрашивают БД. Это не экзотический подход, это просто очевидное неумное решение. Вы должны понять, что в 2003 году это была вершина «шаблонной лихорадки» Исходя из того, что я мог сказать, люди думали, что присвоение новых образцов будет их путем к славе и богатству. Не поймите меня неправильно, я думаю, что концепция шаблона чрезвычайно полезна для описания решений абстрактно. Вещи просто немного сошли с рельсов. Это прискорбно, потому что это вызвало большой цинизм в отношении концепции паттерна в целом. Только в этом контексте имеет смысл говорить об этом как о «неортодоксальном» решении. Это' Схожи с ортодоксальностью вокруг ORM или DI-контейнеров. Неиспользование их считается неортодоксальным, даже несмотря на то, что люди создавали программное обеспечение задолго до того, как эти инструменты появились, и во многих случаях эти инструменты излишни.

Итак, вернемся к «исправить все». Простым примером является расчет средств. Простое решение состоит в суммировании чисел и делении на количество значений. Если вы добавляете или изменяете число, вы просто делаете это снова, с самого начала. Вы можете отслеживать сумму и количество чисел, а когда кто-то добавляет число, вы увеличиваете количество и добавляете его к сумме. Теперь вы не добавляете все цифры снова. Если вы когда-либо работали с Excel с формулой, которая ссылается на диапазон, и изменили одно значение в этом диапазоне, у вас есть пример шаблона «исправить все», то есть любая формула, которая имеет ссылку на этот диапазон, будет пересчитываться независимо от того, это значение было релевантным (например, используя что-то вроде sumif ()).

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

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

Не уверен, что это «шаблон проектирования», но я бы классифицировал этот тип поведения как конфигурацию конечного состояния или желаемую конфигурацию состояния в духе Puppet, Chef или Powershell DSC.

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

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

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

Похоже, принципы реактивного программирования. «Исправить все» просматривает текущее состояние «ядра» и распространяет все остальное, на что должно быть оказано влияние - «вычисленные состояния». Если вы оптимизируете этот вывод, он может достичь высокой эффективности, а-ля React, если все сделано наивно, производительность может быть неоптимальной, хотя все еще может быть достаточно быстрой.