Наследование НЕ предназначено для повторного использования кода, оно предназначено для подстановки. Когда думают о наследовании, повторное использование кода случается .
Многие разработчики думают о возможности повторного использования, когда думают о наследовании, но имейте в виду, что это неправильная аргументация. Для повторного использования кода следует отдавать предпочтение композиции, а не наследованию.
Когда вы думаете о замене, вы можете думать о наследовании.
Практический пример понимания полиморфизма - это когда вы смотрите на шаблон проектирования под названием «Стратегия ".
Стратегия позволяет изменять алгоритм во время выполнения без изменения компонента оркестратора.
Например, представьте себе видеоигру, в которой вы управляете солдатами с развивающимся оружием.
Main алгоритм (алгоритм оркестратора) заключается в перемещении солдата и поражении любого врага. Уровень 1, у вас есть нож. Уровень 2, у вас будет пистолет. Уровень 3, у вас будет бомба. Et c.
Вы не хотите явно иметь дело с каким-либо оружием в рамках вашего основного алгоритма, вам нужен такой псевдокод внутри, скажем, класс Soldier
:
hit() {
weapon.use(); // so generic !
}
вместо:
hit() {
if(weapon instance of Knife)
....
else if(weapon instance of Gun)
....
else if(weapon instance of Bomb)
....
// what if you create another weapon for a further level...you would have to alter this class to add another 'else if' clause, bad!
}
Итак, чтобы использовать первый способ, более краткий и solid, вам придется использовать полиморфизм, создав подклассы Weapon
класса с соответствующими подклассами (Knife
, Gu
, Bomb
) реализация метода use
.
Полиморфизм = weapon
может принимать несколько форм / структур / поведения во время выполнения.
Итак, в В этом случае вы используете composition
, чтобы изменить используемое оружие во время выполнения, и вы используете полиморфизм, чтобы оркестратор не знал точное используемое оружие.
Это делает код гибким, надежным и простым в обслуживании.