Правильное понимание и обоснование использования полиморфизма

@bnt · Регистрация: 10.11.2016

Студворк — интернет-сервис помощи студентам

Всем привет!
Помогите понять полиморфизм правильно. Так как примеров в Интернете много и все они отличаются друг от друга.

Как я его понимаю. Это когда свойство базового класса может использовать методы производных классов.

Пример кода.

PHP
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
class user {
 
    public $type = 'default_user';
 
    public function setName (){
    
    }
    public function Call (){
          return $this->setName();
    }
}
 
 class admin extends user {
     public function setName (){
         return $this->type = "admin<br>";
     }
 }
 
class superUsers extends user {
    public function setName (){
        return $this->type = "superUser";
    }
 
}
 
$super = new superUsers;
$admin = new admin;
$superUser = new superUsers;
 
 
echo $super->call();
echo $admin->setName();
echo $superUser->test();

Но часто можно встретить примеры где пишут вот так.

PHP
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
class user {
 
    public $type = 'default_user';
 
    public function setName (){
    
    }
    public function Call (){
          return $this->setName();
    }
}
 
 class admin extends user {
     public function setName (){
         return $this->type = "admin<br>";
     }
 }
 
class superUsers extends user {
    public function setName (){
        return $this->type = "superUser";
    }
 
}
$super = new superUsers;
$admin = new admin;
$superUser = new superUsers;
 
 
echo $super->call();
echo $admin->setName();
echo $superUser->test();

Или вообще не пишут в базовом классе метод setName.
Все приведенные мной примеры показывают полиморфизм или только первый ?
Заранее спасибо !

@Madrid · 26.12.2016, 13:31

Сообщение от Jodah

Если мы говорим об ООП в PHP, то помимо просто переопределения есть возможность унификации принимаемых параметров в методах.

Это лишь особенности наследования.

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

Заострять внимание на полиморфизме в ООП и возносить его до уровня кита - признак оленя.

Сообщение от Jodah

Сама по себе замена массива на stdClass не имеет ничего плохого.

Это ООП головного мозга

Сообщение от Jodah

То здесь скорее вопрос к адекватности программиста, чем к самому ООП.

Такое сплошь и рядом. Рад, что хоть тут нашел понимание.

Сообщение от Jodah

Зависит от квалификации программистов

Вот и я о том же. ООП требует более высокую квалификацию, ибо он более сложен в понимании...

Сообщение от Azdeman

Так вот, предлагаю Вам создать тему в которой вы опишите все свои мысли и доводы про ООП.

Создайте тему и надергайте моих цитат, с которыми Вы не согласны, обсудим.

Добавлено через 11 минут

Сообщение от Jodah

(array) $book

А многоуровневый массив?

А обратное преобразование в объект нужного типа?

А можно этим псевдопрограммированием не заниматься, а сразу использовать массив, где он подходит по смыслу.

@tarasalk · 26.12.2016, 14:21

Не по теме:

Сообщение от Madrid

надергайте моих цитат, с которыми Вы не согласны

Как то все 312 ваших сообщений цитировать не хочется:p

@Madrid · 26.12.2016, 14:51

Не по теме:

Сообщение от tarasalk

Как то все 312 ваших сообщений цитировать не хочется

Вы не согласны со всеми сообщениями?
312 сообщений - в ООП?

@Jodah · 26.12.2016, 20:53

Сообщение от Madrid

Это лишь особенности наследования.

А умножение - это всего лишь упрощённое сложение, следовательно умножение - ерунда. А кто считает, что умножение нужно обязательно проходить в школе - тот олень.

Сообщение от Madrid

Это ООП головного мозга

Это предвзятость с вашей стороны. Возвращаясь к главному вопросу, можете привести нормальный пример неприменимости ООП? Не возню с переменными, а сам подход.

Например, когда помогаю студентам (т.е. пишу весь код за них) с написанием курсовых, пишу только в процедурном стиле. Потому что студент и без ООП может заблудиться в двух соснах, даже когда каждая строчка кода подробно прокомментирована.

Можете назвать нечто подобное для реальной разработки, когда ООП действительно не выгоден для проекта?

Сообщение от Madrid

Вот и я о том же. ООП требует более высокую квалификацию, ибо он более сложен в понимании...

Это минус только если вам в команду нужен новичок, плохо понимающий в разработке и работающий за еду.

А если мы хотим найти, например, такого замечательного программиста, как вы, который знает, когда использовать процедурный стиль, а когда ООП, получается этот специалист в любом случае должен знать ООП. Иначе как он поймёт, когда применять ООП, а когда нет?

@Madrid · 30.12.2016, 14:59

Сообщение от Jodah

А умножение - это всего лишь упрощённое сложение, следовательно умножение - ерунда.

Только не нужно демагогии.

Сообщение от Jodah

пишу только в процедурном стиле. Потому что студент и без ООП может заблудиться в двух соснах

Так и я о том же.
ООП более труден для понимания.
Кстати, я и процедур стараюсь избегать, они тоже увеличивают сложность.

В общем, почитайте о сложности в программировании.

Сообщение от Jodah

Можете назвать нечто подобное для реальной разработки, когда ООП действительно не выгоден для проекта?

Та, вообще, все на все можно натянуть и гордится этим.

Сообщение от Jodah

Это минус только если вам в команду нужен новичок, плохо понимающий в разработке и работающий за еду.

Нам нужен более простой в понимании код.
Вы пишете код для компьютера? Ну и отлично, пишите.

Мы же пишем этот код для себя, нам потом с ним работать.
То, что программист знает ООП, не значит что ООП более понятно ему.

Можно ж написать без {censored} и более понятно для окружающих. А то есть такие, начитаются каких-то статей и давай пихать свой код, более никому не понятный, по проекту.

Сообщение от Jodah

получается этот специалист в любом случае должен знать ООП

Знать ООП и пихать его во все щели - это 2 большие разницы.
Ну и голову полиморфизмом забивать не стоит.

Ну вот где может понадобиться "знание" об ООП полиморфизме?

Комментарий модератора

Использование нецензурных выражений запрещено в любом виде.

@Usaga · 31.12.2016, 08:39

Сообщение от Madrid

То, что программист знает ООП, не значит что ООП более понятно ему

А мне, почему то, казалось, что значит

ООП - инструмент, овладев которым, можно писать быстрее, больше, качественнее. Если ты делаешь двухстраничную поделку для себя, то да - ООП тут не нужен. Вообще ничего не нужно. Пиши хоть на ассемблере.

Но когда речь заходит о работе над большим и сложным проектом, за не свои деньги и в ограниченные сроки, то тут уж извините: либо ты сделаешь быстро и качественно (и так, чтобы поддерживать это всё потом можно было), либо это сделают конкуренты.

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

Как-то так

@Madrid · 31.12.2016, 13:38

Сообщение от Usaga

А мне, почему то, казалось, что значит

Это Вам казалось.

Предыдущие ораторы признали, что ООП менее понятно.
Но это ни в коем случае не значит, что оно под запретом! Во многих случаях ООП и понижает сложность.

Сообщение от Usaga

ООП - инструмент, овладев которым, можно писать быстрее, больше, качественнее.

Вы преподаватель ООП курсов?

Сообщение от Usaga

Если ты делаешь двухстраничную поделку для себя, то да - ООП тут не нужен. Вообще ничего не нужно.

Сразу видно неграмотный подход.

Вконтакте вот почему-то не ООП

Сообщение от Usaga

Но когда речь заходит о работе над большим и сложным проектом, за не свои деньги и в ограниченные сроки, то тут уж извините: либо ты сделаешь быстро и качественно (и так, чтобы поддерживать это всё потом можно было), либо это сделают конкуренты.

Ага, только специалисты, которые бьют себя в грудь типа: "Да я пишу на ООП" стоят дороже.
Они все усложняют, а потом да, сидят и правят на поддержке свои же баги.

Да и ООП им как бы не особо то и нужен.
Такие программисты для минимизации собственной ответственности в основном сидят на фреймворках.

Быстро в большинстве случаев не будет стоит дорого.

Наоборот нужно проект затягивать.

Сообщение от Usaga

И замечу, что в таких ситуациях приоритет отдаётся возможностям инструмента и языка, а не понятности кода для "новичка".

Да? Я всю жизнь думал, что код пишется для программистов, а не для компьютеров.

@Usaga · 31.12.2016, 16:35

Сообщение от Madrid

Это Вам казалось.
Предыдущие ораторы признали, что ООП менее понятно.
Но это ни в коем случае не значит, что оно под запретом! Во многих случаях ООП и понижает сложность.

Конечно ООП менее понятно. Оно и должно быть сложнее, это обратная сторона мощи. Бензопила, очевидно, сложнее ножовки и это нормально.

Сообщение от Madrid

Вы преподаватель ООП курсов?

Нет. Я использую ООП в работе. Я - разработчик .NET и использую объектно-ориентированный подход для создания как настольных приложений, так и для веба. И везде оно в кассу. А всё потому, что ООП упрощает работу за счёт того, что позволяет моделировать сложные системы и абстракции. И это позволяет писать модульный и элегантный код (насколько позволяют знания и опыт, конечно).

Всё тоже самое можно получить и используя процедурный подход. Но это потребует куда больше писанины и, соответсвенно, времени. И багов будет больше, ибо больше кода.

И разобраться в таком коде проще. Намного. Хотя, признаться, мне попадался проект, где люди по незнанке сильно перестарались и напроектировали такого... Но я думаю, что используя процедурный подход там лучше бы не стало. Мораль: везде нужна голова, ибо любой инструмент в руках варвара - мусор.

Сообщение от Madrid

Сразу видно неграмотный подход.
Вконтакте вот почему-то не ООП

Откуда такие выводы? Ты видел код вконтакта? Вебный бекэнд? Сервисы обмена сообщений? Службы хранения и обработки мультимедиа-контента? Где можно ознакомиться с этим? Или ты статью об этом видел? Ссылку можно?

Сообщение от Madrid

Ага, только специалисты, которые бьют себя в грудь типа: "Да я пишу на ООП" стоят дороже.
Они все усложняют, а потом да, сидят и правят на поддержке свои же баги.
Да и ООП им как бы не особо то и нужен.
Такие программисты для минимизации собственной ответственности в основном сидят на фреймворках.
Быстро в большинстве случаев не будет стоит дорого. Наоборот нужно проект затягивать.

Это только твои домыслы и инсинуации. Ничем не подкреплённые. Ни опытом, ни знаниями.

Мне на работе никто не платит ни за количество строк кода, ни за сложность, ни за "ООП". От меня нужно в конце недели, чтобы было "вон то" и оно могло "вот так". И чтобы после меня всё было понятно, так, чтобы другой товарищь потом мог допилить\переделать, если возникнет необходимость.

Сообщение от Madrid

Да? Я всю жизнь думал, что код пишется для программистов, а не для компьютеров.

А ты попробуй написать что-нибудь мало-мальски сложное. И при этом не дай бог, ты используешь какой-нибудь сложный приём или библиотеку существенно облегчающую твою работу! Ведь нубам оно непонятно! А пишешь ты не продукт самодстаточный, а только учебное пособие для этих самых нубов. Надеюсь аналогия с твоим утверждением и его глупостью ясно видны.

Вообще, что-то доказывать мне уже не очень интересно. Я не в первый раз это делаю. Пока ты сам не пройдёшь через геморрой, кровь и слёзы при работе с "простым и понятным" процедурным кодом, пока ты не поучавствуешь в работе над проектом столь большим, что он сам себя своим же весом давит, то пользы от использования ООП видно не будет.

Добавлено через 6 минут

Сообщение от Madrid

Да? Я всю жизнь думал, что код пишется для программистов, а не для компьютеров.

Грамотно использование ООП делает код проще и читабельнее. Просто читать код должен специалист. И это справедливо в любой области деятельности, не только в программировании.

@Madrid · 31.12.2016, 17:00

Сообщение от Usaga

Я - разработчик .NET

Ну так чего Вы влезли в ветку PHP?

Я же в .NET не лезу...

Сообщение от Usaga

А всё потому, что ООП упрощает работу за счёт того, что позволяет моделировать сложные системы

Та не нужно в вебе ничего сложного моделировать.

Да и поймите.
Я не против ООП вообще, я говорю, что не везде его стоит тулить.
А вы зациклились.

Сообщение от Usaga

Всё тоже самое можно получить и используя процедурный подход.

Я ж уже писал.
Я стараюсь и процедур не использовать, ибо они тоже увеличивают сложность кода.

Сообщение от Usaga

И разобраться в таком коде проще.

Хм, но Вы же сами сказали, что оно менее понятно...

Сообщение от Usaga

Мораль: везде нужна голова, ибо любой инструмент в руках варвара - мусор.

Наконец-то.

Сообщение от Usaga

Откуда такие выводы? Ты видел код вконтакта?

Я так понял Вы задаете вопросы по второму моему вопросу?

Погуглите.

Сообщение от Usaga

Это только твои домыслы и инсинуации. Ничем не подкреплённые. Ни опытом, ни знаниями.

Игра слов.
Какие должны быть у меня знания и опыт, если программисты ООП-шники почти целиком и полностью используют фреймворки?..

Сообщение от Usaga

И при этом не дай бог, ты используешь какой-нибудь сложный приём или библиотеку существенно облегчающую твою работу! Ведь нубам оно непонятно!

Хм, но при чем тут библиотека?

Сообщение от Usaga

Пока ты сам не пройдёшь через геморрой, кровь и слёзы при работе с "простым и понятным" процедурным кодом

Че Вы зациклились на этом процедурном коде?

Сообщение от Usaga

Грамотно использование ООП делает код проще и читабельнее.

Хм, ты же сам писал, что ООП - не проще.

А тут вдруг такое.

@Madrid · 02.01.2017, 13:43

тест прошел успешно

@pav1uxa · 03.01.2017, 09:38

Не по теме:

Сообщение от Madrid

Ну так чего Вы влезли в ветку PHP?

А Вы? :D

@Usaga · 04.01.2017, 15:43

Сообщение от Madrid

Ну так чего Вы влезли в ветку PHP?

А что? Тут какой-то другой мир? Почему мне нельзя зайти в гости с коллегам из соседнего цеха?

Сообщение от Madrid

Та не нужно в вебе ничего сложного моделировать.

Это тебе не нужно. А остальным нужно. По себе знаю.

Сообщение от Madrid

Я стараюсь и процедур не использовать, ибо они тоже увеличивают сложность кода

Я уже об этом выше писал: попробуй написать что-нибудь сложнее echo '<h1>Hello</h1>' (или как оно правильно) и тебе откроется страшная правда о пользе управлением сложностью и структурой кода.

Сообщение от Madrid

Хм, но Вы же сами сказали, что оно менее понятно...

Не нужно передёргивать. Я сказал, что освоить ООП сложнее. Но конечный результат будет проще читать. Т.е. потратить время на освоение - потом делать быстрее и конечный код понятнее (тому, кто ООП осилил, конечно).

Сообщение от Madrid

Я так понял Вы задаете вопросы по второму моему вопросу?
Погуглите.

Нет, спасибо.

Сообщение от Madrid

Какие должны быть у меня знания и опыт, если программисты ООП-шники почти целиком и полностью используют фреймворки?..

Смешно.
Во-первых, фрейворк = заготовленный, очень обобщённый каркас приложения и набор библиотечных функций. Оно не обязано использовать ООП. Если использует (или требует от программиста), то только потому, что это удобно.
Во-вторых, ООП с фрейморками никак не коррелирует. Для того, чтобы завернуть что-то в класс или сотворить пару-тройку паттернов никакие библиотеки и фрейворки не нужны. За доказательствами можно сходить в цех "С++" или в ".NET".

Сообщение от Madrid

Хм, ты же сам писал, что ООП - не проще.

Ещё раз: освоить сложнее - работать проще.

Сообщение от Madrid

Хм, но при чем тут библиотека?

Это аналогия. ООП упрощает жизнь, если ООП - зло, то и любые попытки упрощения и ускорения своей работы - тоже зло. Что чушь, конечно же.

Сообщение от Madrid

тест прошел успешно

Поздравляю.

@Madrid · 04.01.2017, 16:18

Сообщение от Usaga

Это тебе не нужно. А остальным нужно. По себе знаю.

Значит ты влез в соседний цех зря...
Это как-то даже тупо смотрится.

Дальше даже читать лень, ибо бессмысленно.

@Usaga · 04.01.2017, 16:34

Сообщение от Madrid

Значит ты влез в соседний цех зря...
Это как-то даже тупо смотрится.

Нет, не тупо. Если я взялся за .Net, то это меня не прибивает гвоздями к какой-то касте. Да и ООП у всех один

Сообщение от Madrid

Дальше даже читать лень, ибо бессмысленно.

Согласен. Спорить тут не о чем.

@andr-xw · 11.01.2017, 04:12

Не по теме:

Сообщение от Usaga

А что? Тут какой-то другой мир?

Да. Тут говнокодеры говнокодят на ООП, и код получается нечитабельным и не понятным. А тру сениоры, вроде Madrid'а, бьют их за это по рукам и пытаются научить уму-разуму и процедурному стилю.

Новые блоги и статьи Все статьи Все блоги /
Транслитерация текста с кириллицы на латиницу (вариант №3) Maks 15.11.2026 Обновленная версия предыдущей обработки. Изменения коснулись букв: Ъ, Ы, Ь, Э, отображения которых зависят от положения реквизита "Транслитерация имён". Изменено отображение буквы Й. Добавлена. . .	Транслитерация текста с кириллицы на латиницу (вариант №2) Maks 13.11.2026 Обновленная версия ранее созданной обработки. Добавлено: - Проверка исходного текста на кириллицу, через обращение к стандартной функции "ТолькоКириллицаВСтроке" из общего модуля. . .	Часы с термометром и праздничным календарем yariko 12.11.2026 Сегодня мы рассмотрим как можно сделать отличные многофункциональные часы. Итак, поставим конкретную задачу: разработать часы с календарем, двумя термодатчиками, выводом поздравительных сообщений. . .	Транслитерация текста с кириллицы на латиницу (вариант №1) Maks 11.11.2026 Решил облегчить жизнь себе и коллегам админам при создании электронных почтовых ящиков для пользователей, в результате написал обработку "Транслитерация текста" с кириллицы на латиницу, а в ней. . .
Книги по геймдизайну, левел-дизайну, игровым механикам и проектированию игрового опыта 8Observer8 08.11.2026 Содержание блога \| English Version 1. 2003 - 06 - Designing Virtual Worlds (1st Edition) Автор: Richard A. Bartle \| Объем: 768 стр. Ссылки: Amazon . . .	Как только я захожу к себе в свою комнату я сразу же с себя снимаю свои трусы. Ответ от Джемени ИИ. zorxor 08.11.2026 Джемени, как только я захожу к себе в свою комнату я сразу же с себя снимаю свои трусы. Многие люди, возвращаясь домой, сразу переодеваются в максимально свободную одежду или вовсе предпочитают. . .	Паттерн очереди действий/команд (Action / Command Queue). Система очереди действий и кат-сцен с SDL3 Callbacks, cglm и OpenGL 8Observer8 07.11.2026 Содержание блога \| English Version Руководство для начинающих по реализации паттерна очереди действий/ команд (Action / Command Queue) на C++ (C++20) с использованием официального SDL3 Callbacks. . .	Проверка полного ФИО в типовом справочнике Maks 07.11.2026 Решение реализовано в конфигурации КА2, на примере справочника "КонтактныеЛицаПартнеров". Задача: Запрет инициалов. Не допускаеть использование сокращений вида "И. И. ", "И. И. ", "И И" и. . .

@Madrid 14 / 50 / 3 Регистрация: 26.12.2009 Сообщений: 406
	02.01.2017, 13:43
	тест прошел успешно 0