0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Как мы выяснили в предыдущем уроке, многие объекты в ООП не являются абстракцией данных, а используются как способ сохранить конфигурацию для выполнения повторяющихся действий, таких как генерация HTML из Markdown или определение города по IP. Конфигурация осуществляется через передачу опций в конструктор объекта, а сами опции хранятся внутри и используются для всех последующих вызовов.</p>
1
<p>Как мы выяснили в предыдущем уроке, многие объекты в ООП не являются абстракцией данных, а используются как способ сохранить конфигурацию для выполнения повторяющихся действий, таких как генерация HTML из Markdown или определение города по IP. Конфигурация осуществляется через передачу опций в конструктор объекта, а сами опции хранятся внутри и используются для всех последующих вызовов.</p>
2
<p>Но что если для конкретного запроса, нужно временно установить опции, отличные от тех, что были переданы в конструктор? Для выхода из этой ситуации есть три возможных решения.</p>
2
<p>Но что если для конкретного запроса, нужно временно установить опции, отличные от тех, что были переданы в конструктор? Для выхода из этой ситуации есть три возможных решения.</p>
3
<h2>Создание нового объекта</h2>
3
<h2>Создание нового объекта</h2>
4
<p>Самое простое решение сводится к созданию нового объекта в том месте где нам нужно. Это решение хоть и простое, но обладает рядом недостатков. Главный недостаток связан с невозможностью подмены реализации (тот самый полиморфизм, о котором мы будем говорить в будущем), так как объект создается не на этапе конфигурирования системы, а в том месте, где происходит вызов. Это, в свою очередь, ведёт к тому, что придётся дублировать общие опции, а тестирование станет затруднительным (если не невозможным).</p>
4
<p>Самое простое решение сводится к созданию нового объекта в том месте где нам нужно. Это решение хоть и простое, но обладает рядом недостатков. Главный недостаток связан с невозможностью подмены реализации (тот самый полиморфизм, о котором мы будем говорить в будущем), так как объект создается не на этапе конфигурирования системы, а в том месте, где происходит вызов. Это, в свою очередь, ведёт к тому, что придётся дублировать общие опции, а тестирование станет затруднительным (если не невозможным).</p>
5
<h2>Сеттеры</h2>
5
<h2>Сеттеры</h2>
6
<p>Самый страшный вариант связан с использованием сеттеров.</p>
6
<p>Самый страшный вариант связан с использованием сеттеров.</p>
7
<p>Изменяемое состояние - самое сложное, что есть в программировании. Его наличие приводит практически ко всем проблемам, с которыми мы встречаемся, и создает трудноотловимые и опасные баги. Догадайтесь, что пойдёт не так после выполнения последних двух строк? Наш объект $ipgeo используется совместно всеми частями системы, из этого следует, что его изменение в одном месте, повлияет на все последующие вызовы. В случае работы с Markdown всё может быть ещё опаснее, так как неправильный вывод порождает дыры в безопасности, а конкретно - возможность провести<a>XSS</a>:</p>
7
<p>Изменяемое состояние - самое сложное, что есть в программировании. Его наличие приводит практически ко всем проблемам, с которыми мы встречаемся, и создает трудноотловимые и опасные баги. Догадайтесь, что пойдёт не так после выполнения последних двух строк? Наш объект $ipgeo используется совместно всеми частями системы, из этого следует, что его изменение в одном месте, повлияет на все последующие вызовы. В случае работы с Markdown всё может быть ещё опаснее, так как неправильный вывод порождает дыры в безопасности, а конкретно - возможность провести<a>XSS</a>:</p>
8
<p>sanitize - флаг, отвечающий за включение безопасного рендеринга. Если его выключить, то теги script вставленные в Markdown отобразятся как есть. Такое иногда нужно и допустимо для своего собственного текста (например, на Хекслете это уроки), но недопустимо для текста, который вводят пользователи. Изменение объекта md создает дыру в безопасности. Избежать её можно не забыв вернуть опцию обратно:</p>
8
<p>sanitize - флаг, отвечающий за включение безопасного рендеринга. Если его выключить, то теги script вставленные в Markdown отобразятся как есть. Такое иногда нужно и допустимо для своего собственного текста (например, на Хекслете это уроки), но недопустимо для текста, который вводят пользователи. Изменение объекта md создает дыру в безопасности. Избежать её можно не забыв вернуть опцию обратно:</p>
9
<p>В силу человеческого фактора, программист обязательно забудет это сделать. Такой код, в котором сначала что-то меняется в одну сторону, а потом восстанавливается обратно, почти всегда говорит о проблемах архитектуры и его можно написать безопасно.</p>
9
<p>В силу человеческого фактора, программист обязательно забудет это сделать. Такой код, в котором сначала что-то меняется в одну сторону, а потом восстанавливается обратно, почти всегда говорит о проблемах архитектуры и его можно написать безопасно.</p>
10
<h2>Новые опции на время запроса</h2>
10
<h2>Новые опции на время запроса</h2>
11
<p>Правильный способ решает все проблемы указанные выше. Его использование основано на передаче дополнительного параметра в метод. Этот параметр содержит временные опции, которые применяются только для данного запроса.</p>
11
<p>Правильный способ решает все проблемы указанные выше. Его использование основано на передаче дополнительного параметра в метод. Этот параметр содержит временные опции, которые применяются только для данного запроса.</p>
12
<p>Теперь все в порядке. Sanitize включён глобально, но в конкретном запросе он был переопределён $md->render($markdown, ['sanitize' => false]) и это никак не отражается на последующих вызовах метода render.</p>
12
<p>Теперь все в порядке. Sanitize включён глобально, но в конкретном запросе он был переопределён $md->render($markdown, ['sanitize' => false]) и это никак не отражается на последующих вызовах метода render.</p>