0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<h2>Формирование объектов</h2>
1
<h2>Формирование объектов</h2>
2
<p>Посмотрите на функцию ниже и скажите, является ли она полиморфной?</p>
2
<p>Посмотрите на функцию ниже и скажите, является ли она полиморфной?</p>
3
<p>С одной стороны да, пользователь передаётся снаружи и у нас есть возможность его подменить, передав туда объект другого класса. С другой стороны, внутри функции явно используется класс EmailSender и его подменить не получится без переписывания самого кода.</p>
3
<p>С одной стороны да, пользователь передаётся снаружи и у нас есть возможность его подменить, передав туда объект другого класса. С другой стороны, внутри функции явно используется класс EmailSender и его подменить не получится без переписывания самого кода.</p>
4
<p>Этот код демонстрирует простую, но важную идею. Полиморфизм подтипов возможен тогда, когда объект попадает в функцию снаружи, а не конструируется прямо внутри неё.</p>
4
<p>Этот код демонстрирует простую, но важную идею. Полиморфизм подтипов возможен тогда, когда объект попадает в функцию снаружи, а не конструируется прямо внутри неё.</p>
5
<h2>Проверка типов</h2>
5
<h2>Проверка типов</h2>
6
<p>Ещё один пример с подвохом. Есть ли полиморфизм в коде ниже?</p>
6
<p>Ещё один пример с подвохом. Есть ли полиморфизм в коде ниже?</p>
7
<p>В данном примере, вроде бы, всё нормально, объект передаётся снаружи, но есть одна загвоздка. Внутри функции явно проверяется тип, а это значит, что поведение определяется не типом, а сама функция решает как себя вести. Более того, функция жёстко связана с теми типами, которые определены внутри неё и её придётся переписывать при их изменении. И как результат - отсутствие полиморфизма подтипов.</p>
7
<p>В данном примере, вроде бы, всё нормально, объект передаётся снаружи, но есть одна загвоздка. Внутри функции явно проверяется тип, а это значит, что поведение определяется не типом, а сама функция решает как себя вести. Более того, функция жёстко связана с теми типами, которые определены внутри неё и её придётся переписывать при их изменении. И как результат - отсутствие полиморфизма подтипов.</p>
8
<p>Проверка типа иногда встречается и её можно использовать к месту, чтобы не усложнять код, но чаще, она говорит о плохом дизайне. Такой код, можно сказать, не соответствует ООП в современном его понимании.</p>
8
<p>Проверка типа иногда встречается и её можно использовать к месту, чтобы не усложнять код, но чаще, она говорит о плохом дизайне. Такой код, можно сказать, не соответствует ООП в современном его понимании.</p>
9
<p>Для решения задачи выше, есть несколько подходов:</p>
9
<p>Для решения задачи выше, есть несколько подходов:</p>
10
<ul><li><p>Перенос логики внутрь самих классов. Тогда код функции превратится в такой: $user->sayHi(). С этим подходом нужно быть осторожным, так как легко получить<a>божественный объект</a>. Гораздо чаще нужно применять другой подход.</p>
10
<ul><li><p>Перенос логики внутрь самих классов. Тогда код функции превратится в такой: $user->sayHi(). С этим подходом нужно быть осторожным, так как легко получить<a>божественный объект</a>. Гораздо чаще нужно применять другой подход.</p>
11
</li>
11
</li>
12
<li><p>Понадобится добавить новый интерфейс в виде методов isUser и isGuest.</p>
12
<li><p>Понадобится добавить новый интерфейс в виде методов isUser и isGuest.</p>
13
<p>И хотя кода меньше не стало, всё же это полиморфизм подтипов. Код завязан на методы, а не на типы. Изменение структуры классов не коснётся этой функции если сама логика останется той же.</p>
13
<p>И хотя кода меньше не стало, всё же это полиморфизм подтипов. Код завязан на методы, а не на типы. Изменение структуры классов не коснётся этой функции если сама логика останется той же.</p>
14
</li>
14
</li>
15
</ul>
15
</ul>