Полиморфизм – это не то, что вы подумали. На самом деле, полиморфизм встречается далеко не только в ООП. Да, он – один из принципов ООП, помимо абстракции, инкапсуляции и наследования. Но полиморфизм не ограничивается этой парадигмой.
Итак, после такого загадочного вступления, приступим к сути!
Полиморфизм шире, чем кажется
Полиморфизм появился задолго до первых языков с поддержкой объектно-ориентированного подхода.
Чаще всего под понятием полиморфизма понимают именно ООП-шную часть – когда мы берём класс или интерфейс, наследуем от него разные классы и путём переопределения методов базового класса меняем поведение в производных классах. А потом можем со всеми объектами работать одинаковым образом и в переменную с типом базового класса на самом деле класть объект производного класса.
Однако это далеко не всё.
Полиморфизм в программировании — способность использовать один и тот же код с разными типами переменных. Да, никакого наследования, объектов или интерфейсов в определении!
Если кратко, то полиморфизм можно условно поделить так:
Давайте по очереди разберёмся со всеми видами полиморфизма. И в первую очередь – с самым популярным.
Динамический полиморфизм
Динамический полиморфизм подразумевает, что выбор конкретной операции происходит во время выполнения программы – в зависимости от предоставленного типа переменной.
Полиморфизм в ООП
Мы можем работать со многими классами одинаково, если они все – наследники одного и того же класса (или интерфейса). Получается, ООП-шный полиморфизм без наследования не существует. В переменную с типом класса-родителя мы можем положить объект класса-наследника:
|
1 |
Device device = new Phone(); //класс Phone - наследник класса Device |
|
1 2 3 |
public class Phone extends Device { ... } |
Очень важная ремарка – при преобразовании ссылочных типов (когда объект типа Phone мы кладём в переменную с типом Device, например) сам объект физически ни во что не преобразовывается. Однако после преобразования с ним можно работать как с объектом типа Device.
Благодаря полиморфизму классов можно работать с объектами разных классов-наследников Device как с объектами Device. Например, добавить их в один массив:
|
1 2 3 4 |
Device[] devices = new Device[3]; devices[0] = new Phone(); devices[1] = new Laptop(); devices[2] = new TV(); |
Давайте рассмотрим пример с переопределением методов. Он позволит изменять поведение классов-наследников. Допустим, мы пишем калькулятор. Он будет уметь делать бинарные операции, где требуются 2 операнда: +, -, * и /. Ну ещё давайте степень ^ добавим. И мы хотим, чтобы вся работа с операциями была однородной. Чтобы нам не нужно было знать, какая конкретная операция выполняется – чтобы мы со всеми этими операциями могли работать одинаковым образом.
Операция – это абстрактное понятие, которое ничего не говорит о реализации. Это будет у нас абстрактный класс Operation:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
public abstract class Operation { protected double firstOperand; protected double secondOperand; public Operation(double firstOperand, double secondOperand) { this.firstOperand = firstOperand; this.secondOperand = secondOperand; } public void setFirstOperand(double firstOperand) { this.firstOperand = firstOperand; } public void setSecondOperand(double secondOperand) { this.secondOperand = secondOperand; } public abstract double calculate(); protected abstract String getToken(); @Override public String toString() { return firstOperand + " " + getToken() + " " + secondOperand + " = " + calculate(); } } |
Этот класс имеет 2 операнда типа double (причём protected, чтобы классы-наследники имели доступ к операндам для расчётов). Также он самостоятельно определяет метод toString(), переопределяя его реализацию из класса Object. Помимо этого, абстрактный класс Operation имеет 2 абстрактных метода. Метод calculate() будет рассчитывать результат выражения. В свою очередь, метод getToken() возвращает строковое представление символа операции (например, “+”). Это понадобилось как раз для метода toString() – чтобы строковое представление операции включало её символ. Ведь у абстрактной операции нет символа.
Экземпляр абстрактного класса нельзя создать. Зато от него можно наследовать другие классы. Они будут конкретными реализациями операций +, -, *, / и ^:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public class PlusOperation extends Operation { public PlusOperation(double firstOperand, double secondOperand) { super(firstOperand, secondOperand); } @Override public double calculate() { return firstOperand + secondOperand; } @Override protected String getToken() { return "+"; } } |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
public class MinusOperation extends Operation { public MinusOperation(double firstOperand, double secondOperand) { super(firstOperand, secondOperand); } @Override public double calculate() { return firstOperand - secondOperand; } @Override protected String getToken() { return "-"; } } |
Думаю, насчёт остальных операций вы уже догадались. Что нам вся эта иерархия даёт? Так мы теперь можем со всеми операциями работать, как с Operation! Более того, благодаря полиморфизму мы в любой момент сможем расширить количество возможных операций, просто дописав новых классов-наследников от класса Operation. И для этого не придётся изменять код ни Operation, ни имеющихся классов-наследников, ни тот код, что обращается к классу Operation и его методам.
Например, внутри функции processOperation() абсолютно нет необходимости знать, какая именно операция была ей передана. Ей вообще всё равно. Без разницы! Ведь со всеми операциями, наследуемыми от Operation, можно работать, как с Operation:
|
1 2 3 4 5 6 7 |
private static void processOperation(Operation operation) { operation.calculate(); operation.setFirstOperand(4); operation.setSecondOperand(2.82); operation.toString(); ... } |
Да, и например, можно сложить всё в один список, всех самых разных операций напихать, а потом куда-нибудь передать и в цикле всё вывести в консоль:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
public class Main { public static void main(String[] args) { List<Operation> operations = createOperations(); printOperations(operations); } private static List<Operation> createOperations() { List<Operation> operations = new ArrayList<>(); operations.add(new PlusOperation(3.9, 5.4)); operations.add(new MinusOperation(10, 2.2)); operations.add(new MultiplyOperation(10.5, 2)); operations.add(new DivideOperation(100, 20)); operations.add(new PowerOperation(4, 3)); return operations; } private static void printOperations(List<Operation> operations) { for (Operation operation : operations) { System.out.println(operation.toString()); } } } |
Вот такие чудеса. Полиморфизм в ООП дарит взаимозаменяемость. Один компонент можно вставить на место другого и менять их как перчатки. Всё равно один и тот же код сможет обрабатывать объекты разных классов. Это потому, что они имеют единое определение в Operation. Они имеют единые методы для доступа к ним. При этом, если объявить какой-нибудь дополнительный метод в PlusOperation, например, то вызвать его не получится, если у вас будет Operation operation = new PlusOperation(). Получится только при PlusOperation operation = new PlusOperation(). То есть при контейнере этого класса, а не родительского.
Статический полиморфизм
Статический полиморфизм знает, какая операция будет выполняться, ещё на этапе компиляции программы. То есть до её запуска и выполнения.
Перегрузка
Перегрузка – это полиморфизм. Одно имя функции – несколько реализаций. А какую применить в каждом конкретном случае – зависит от типов переменных. Только это уже не динамический полиморфизм, как переопределение, а статический. Потому что в случае перегрузки во время компиляции компилятор знает, какую функцию связать с вызовом для упавшего в неё типа аргумента. Посмотрите на это:
f(Class1 obj1), f(Class2 obj2) чем-то похоже на obj1.f(), obj2.f().
В коде это сравнение бы выглядело примерно так:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
public static void main(String[] args) { FirstClass firstObject = new FirstClass(); SecondClass secondObject = new SecondClass(); firstObject.doSomething(); secondObject.doSomething(); doSomething(firstObject); doSomething(secondObject); } private static void doSomething(FirstClass object) { ... } private static void doSomething(SecondClass object) { ... } |
Аргумент у перегрузки функции может быть не один, а несколько. Перегруженные функции с одинаковыми именами всё равно представляют полиморфизм – разные типы аргументов, разное количество или их порядок. Но – одно имя (функции).
Обобщённые типы (generic)
Обобщённые типы это не то же самое, что множество наследников одного класса. Ведь generic-и имеют кучу ограничений. И есть базовое различие:
- разные классы-наследники реализуют разную логику методов с одним и тем же названием,
- разные обобщённые типы реализуют одну и ту же логику, абстрагируясь от разницы в типах.
Получается, параметризация, обобщение типов – синоним абстракции типа. Мы не обращаем внимание на тип и проделываем одни и те же операции со всеми. То есть логика одинакова.
За горизонт для примеров плыть не надо. Список List – хороший пример. Это класс, напрямую использующий обобщение типов. В треугольных скобочках вы можете указать, какой тип будет складываться в список. При этом, абсолютно неважно, какой это тип. Операции с ним будут производиться те же самые: складывание в список. То есть абстрагируемся от разницы в типах.
Попробуем реализовать свой собственный простенький класс, использующий обобщение типов:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
public class ArrayBox<T> { private T[] array; private int size; public ArrayBox() { int initialCapacity = 10; array = (T[]) new Object[initialCapacity]; size = 0; } public void add(T element) { if (size == array.length) { expandCapacity(); } array[size] = element; size++; } private void expandCapacity() { int newCapacity = array.length * 2; array = Arrays.copyOf(array, newCapacity); } public T get(int index) { if (index < 0 || index >= size) { throw new IndexOutOfBoundsException("Индекс: " + index + ", размер: " + size); } return array[index]; } public int size() { return size; } } |
Это коробка с массивом элементов внутри. Нам вообще без разницы, какого типа элементы добавлять в массив. А также – какого типа элементы возвращать из массива по индексу (а если индекс за пределами диапазона, порядочно бросаем исключение). Так и работают generic-и.
Затем можно работать с ArrayBox, указывая при создании тип в треугольных скобках:
|
1 2 3 4 5 6 7 |
ArrayBox<String> box = new ArrayBox<>(); box.add("Бокс"); box.add("Каратэ"); box.add("Айкидо"); int boxSize = box.size(); String element = box.get(1); |
Кстати, можно так не один тип задавать, а несколько. Как, например, бывает в словарях, например, HashMap<String, Integer>. Два обобщённых типа:
|
1 2 3 4 5 6 |
public class TwoTyped<T1, T2> { private T1 key; private T2 value; ... } |
Неявное приведение типов
Неявное приведение типов относится к статическому полиморфизму. Да, это тоже полиморфизм. Всё потому, что вы можете с разными типами данных работать одинаково. Ставить +, – и так далее. А компилятор сам уже порешает, что и куда неявно привести. Приведение типов происходит на этапе компиляции программы, когда компилятор автоматически преобразует один тип данных в другой без явного указания программистом.
Когда в вычислениях int приводится к double, компилятор Java автоматически выполняет преобразование типа данных, так как double имеет больший диапазон значений, чем int, и такое преобразование не приводит к потере данных:
|
1 2 3 4 5 |
int intValue = 10; double doubleValue = 5.5; double result = intValue + doubleValue; |
Здесь сложение отрабатывает точно так же, как если бы int-овая переменная имела тип double. Если бы здесь не было статического полиморфизма, компилятор бы ругался на такую операцию, и надо было бы приводить типы вручную:
|
1 |
double result = (double)intValue + doubleValue; |
Теперь насчёт приведения в параметрах функций. Если у функции записан параметр double в сигнатуре, однако она может принимать и аргумент int, и аргумент double и неявно их переводить друг в друга, то она считается полиморфной. Компилятор обнаруживает несоответствие типов и самостоятельно приводит их к нужному типу. Например, int преобразуется в double перед передачей его в функцию:
|
1 2 3 4 5 6 7 8 9 10 11 |
public static void main(String[] args) { int intValue = 5; double doubleValue = 3.5; double firstResult = calculateSquare(intValue); double secondResult = calculateSquare(doubleValue); } private static double calculateSquare(double value) { return value * value; } |
Это полиморфизм, так как функция с одним и тем же именем, даже не перегруженная, может принимать на вход аргументы разных типов. Опять же, если бы не статический полиморфизм в лице неявного приведения типов, пришлось бы вручную прописывать приведение:
|
1 2 |
double firstResult = calculateSquare((double)intValue); double secondResult = calculateSquare(doubleValue); |
Занимательный факт: Из-за того, что в Python и JavaScript типизация динамическая, все переменные изначально обладают полиморфизмом. Они все не имеют строгого типа – следовательно, могут содержать значение любого типа. То есть даже не нужно прописывать типы переменных или типы параметров функции. Но в книжке по теории и практике языков программирования сказано, что в языках программирования с динамической типизацией статический полиморфизм не несёт смысловой нагрузки, так как для переменных не объявляются статические типы.
Операторы
Не ожидали, что такой обычный оператор, как, например, + тоже относится к полиморфизму? А вы посмотрите, какой он многоликий и как подстраивается под ситуацию:
- для числовых типов данных (int, float, double) оператор + выполняет арифметическую операцию – сложение,
- для строк оператор + выполняет конкатенацию, то есть объединение строк в одну строку,
- для объектов оператор + пытается выполнить конкатенацию их строковых представлений, то есть вызывается метод toString().
Выбор конкретной операции происходит во время компиляции, в зависимости от типов операндов у плюса.
Вот мы и разобрали целую кучу видов полиморфизма. Да-да, он не ограничивается одним лишь ООП, как оказалось. Но вы всё равно знайте, что, когда люди говорят волшебное слово “полиморфизм”, они с вероятностью в 98% имеют в виду именно объектно-ориентированный полиморфизм.
