Почему и когда использовать полиморфизм?

УПРОЩЕННОЕ ЗАЯВЛЕНИЕ О ПОЛИМОРФИЗМЕ

Почему и когда использовать полиморфизм?

Объектно-ориентированное программирование или сокращенно ООП является неотъемлемой частью современной архитектуры приложений. ООП включает четыре фундаментальных понятия: ПИРОГ: абстракция, полиморфизм, наследование и инкапсуляция.

Полиморфизм состоит из двух частей: поли (множественный) и морф (форма). Согласно Wikipedia.com, полиморфизм описывается следующим образом:

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

Чтобы было проще:

В мире ООП и объектов каждый отдельный объект, который имеет более одной формы или может быть назначен более чем одному классу, называется полиморфным объектом.

Как инструктор по Java, я постоянно сталкиваюсь с различными вопросами, такими как «что такое полиморфизм?» или «зачем нам вообще это нужно?».

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

Привет, Хатеф !! Зачем нужен полиморфизм? Какой в ​​этом смысл?

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

Основная идея полиморфизма - придать гибкость. Как? Я опишу это на примере Автосервиса:

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

class Technician{
 private String name;
 private Car car
 
 public Technician(String name){
  this.name = name;
 }
  /*
  ... getters and setters
  */
  
  public void repair(Car theCar){
    // ... the body of repair method
  }
}

Все идет нормально. Мы создали наш класс Technician с одним методом repair(), который принимает любой объект типа Car.

Дело здесь:

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

В терминах ООП менеджер может позвонить вам (создать экземпляр Technician объекта) и попросить отремонтировать автомобиль (вызвать вас repair() методом). Но подождите, какой тип автомобиля менеджер собирается передать в качестве theCar аргумента?

Как техник, вас это не беспокоит. Потому что вы можете отремонтировать любую машину B-класса. В результате все приведенные ниже коды верны и имеют смысл:

Technician hatef = new Technician("Hatef");
// create several Car instances
Car yaris = new Toyota();
Car focus = new Ford();
Car azera = new Hyundai();
Renault megane = new Renault();
// create manager object
Manager manager = new Manager();
// now manager calls the technician to start repairing
hatef.repair(yaris); // hatef is able to repair any Car instances
hatef.repair(focus); // focus is a Car instance
hatef.repair(azera); // azera is a Car instance
// now, watch below code, it is wrong because of polymorphism violation. megane is not an object of Car class.
hatef.repair(megane);

Но подождите, почему это так? почему код в последней строке неправильный?

Ответ:

Из-за полиморфизма объекты, такие как yaris, focus, azera, являются ссылочными переменными типа Car, которые указывают на объект другого типа. yaris указывает на Toyota. focus указывает на Ford, а azera указывает на Hyundai.

НО : megane - это ссылочная переменная типа Renault, которая указывает на объект Renault, поэтому неправильно говорить: megane это car !!!!

Итак, суть в том, что, если вы заметили, мы смогли обработать несколько объектов разного типа в одну Car ссылочную переменную. Таким образом, кодирование метода repair() стало для нас очень простым. Нам просто нужно было сказать public void repair(Car theCar){....}.

Считайте, что у нас не было полиморфизма. Как вы могли написать метод repair в его простейшей форме ??

Без полиморфизма вам нужно переписать метод Technician repair(), как показано ниже:

public void repair(Toyota theCar){....}
// an overloaded repair
public void repair(Ford anotherCar){...}
//another overloaded repair
public void repair(Hyundai anotherCar){...}

Ты заметил? Вместо простой строчки кода мне нужно написать кучу перегруженных методов.

В этом магия ПОЛИМОРФИЗМА

Теперь позвольте мне добавить сюда еще несколько концепций:

Просто подумайте о ситуации, когда вы закончили писать код и создали приложение. Настал день, когда вы должны предоставить продукт клиенту. Вдруг к вам подходит покупатель и говорит:

Привет, Хатеф! Знаете ли вы, что мы только что открыли наш новый сервисный отдел? Сейчас мы обслуживаем тяжелые автомобили, такие как автобусы и тракторы: D

Упс !! Я не могу в это поверить. Я не учел это изменение требований заказчика. Мой код может восстанавливать только Ford, Toyota и Hyundai.

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

Дополнительную информацию можно найти в этой замечательной публикации Шаники Эдиривиры: