Что такое ООП? Часть #1 ★ Подробно об основных принципах

Подписаться 2,8 тыс.

Просмотров 7 тыс.

50% 1

Узнаем, почему объектно-ориентированный подход в разработке -- это круто.
Первый ролик из двухсерийки про объектно-ориентированное программирование и проектирование. В нем я излагаю основные принципы ООП на доступных примерах. Так же привожу набор наиболее значимых ООП-ориентированных акронимов. В заключение дан краткий обзор наиболее популярных языков программирования с поддержкой ООП, как то C++, Java, PHP, TypeScript и другие.
=== КРАТКОЕ СОДЕРЖАНИЕ ===
0:00 Вступление
1:00 Абстракция
4:40 Инкапсуляция
7:00 Интерфейс
8:20 Наследование
10:10 Примеси
11:00 Полиморфизм
13:05 ООП-ориентированные акронимы
17:45 Языки с поддержкой ООП
20:30 Заключение
=== СПРАВОЧНАЯ ИНФОРМАЦИЯ ===
Что такое ООП: ru.wikipedia.org/wiki/%D0%9E%...
SOLID: ru.wikipedia.org/wiki/SOLID_(...)
YAGNI: ru.wikipedia.org/wiki/YAGNI
DRY: ru.wikipedia.org/wiki/Don%E2%...
KISS: ru.wikipedia.org/wiki/KISS_(%...)
C++: isocpp.org/
Java: www.java.com/ru/
D: dlang.org/
PHP: www.php.net/
TypeScript: www.typescriptlang.org/
Dart: dart.dev/
Crystal: crystal-lang.org/
#ООП #абстракция #инкапсуляция #наследование #полиморфизм #интерфейс #примеси

Опубликовано:

4 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 50

@NewUser78654 Год назад

В плане поддержки ООП в PHP не соглашусь. Первое, над чем стоит подумать - это смысл ООП. ООП это про объекты. А объекты (в отличии от тех же функций), это то, что должно храниться в памяти. Запомните эту идею. Функция - ничего не храним в памяти. А объект - инстанцировались от класса , и храним его, работаем с ним, уничтожаем его и т.д. Языки C++ JAVA C# и т.д. в общем смысле десктопные. Да у них может быть широкое применение, но они не сильно распространены в вебе. И на JAVA и C# пишут сайты, но это другое. Там другой подход, в отличии от PHP. Так чем же плох PHP в плане ООП? Время жизни программы ограничено. В 90% случаев мы точно знаем предельное время выполнения скрипта (директива в php.ini). В десктопных программах время зачастую не ограничено. Запустили и работает, пока не закроем. И объекты существуют. То есть в PHP предельное время жизни объекта ограничено, что, с точки зрения ООП не очень хорошо. Далее - синтаксис. Методы называют функциями. Статические классы (как в C#) отсутствуют, в результате чего базовый паттерн синглтон (не забываем про магические методы, клонирование и т.д.) реализуется не самым красивым образом. Есть глобальные переменные, которые в неумелых руках нарушают инкапсуляцию. Отсутствует строгая типизация до php 7, позже появилась, но редко применяется. Аргументы метода могут быть любые, нужны дополнительные проверки - код. Присутствует ключевое слово self, абсолютно не нужное (смотрим на C#). Нет чистых геттеров и сеттеров (смотрим на C#) - есть магические методы. После C# PHP - это не ООП. Это ООП сведенный до базовых возможностей. Также часто вижу использование ООП в функциональном стиле, т.е. повсеместное использование статических методов.

@MasterLid Год назад

Боже, какое феерическое занудство, причём мимо кассы. ООП -- это не про то, как долго объект находится в памяти, и не про то, как называется метод. А про архитектуру. В PHP с ООП-ориентированной архитектурой всё в порядке. Не блестяще, не искромётно гениально, но очень даже работоспособно для продакшена. И при чём тут C#? Нравится C# -- программируйте на нём. К чему этот токсичный негатив?

@vanitokurason8445 2 года назад

Идеальная абстракция разказчика! Всё продумано до мелочей: очки скрывают глаза, шляпа - причёску, цвета одежды монохромны. Образ неброский, но очень запоминающийся. Минимум артикуляции, при этом очень чёткая дикция. Никаких телодвижений, рука на столе даже не шелохнулась! Ничего не отвлекает от усвоения материала. Создаётся впечатление, что перед тобой "андроид" (в хорошем смысле). Впадаешь в лёгкое состояние транса, и в фоновом режиме информация пишется сразу в подкорку. Гениальная подача. Вы на 100% перфекционист. Снимаю шляпу! Подписываюсь и иду смотерть все Ваши ролики. Уже Ваш фанат. Спасибо за труд

@e1.st0rm99 3 года назад

Спасибо. Всё просто и понятно. Почему-то вспомнил, как я долго врубался в ООП. Проблема была в том, что подсознательно ожидал чего-то сверх сложного, а на самом деле всё было очень просто. Это и вводило в ступор.

@MasterLid 3 года назад

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

@blackmulthumor Год назад

Та же история у меня была) И не только с классами). Мне так просто некоторые темы давались, что я был уверен, что я их раскрыл не полностью и искал больше инфы.

@azeezbro2731 3 года назад

Классно, все понятно и без воды

@user-ve4ko4pi7i 3 года назад

Спасибо большое! Очень ждём новых видео.

@user-on6zj3yy2q Год назад

Очень круто! Приятно, что без воды и реально по существу, хотя допускаю, что чтобы насладиться этим четким роликом, надо перед ним где-то посмотреть "водяные" невнятные ролики. Классно, что еще вы шутите с серьезным лицом на протяжение ролика (здесь: про американские глубокомысленные акронимы). Это улучшает потребление и обработку информации моим мозгом

@yushchenkoalexey Год назад

Очень крутое видео, большое спасибо!

@mitruslatovous6 2 года назад

Всё хорошо, полёт нормальный (с)

@user-tx5ib9gr9k 3 года назад

Четко

@blackmulthumor Год назад

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

@dodokwak 3 года назад

отлично.

@0xsadcat92 5 месяцев назад

В команте на счет SOLID считаем его как следствие. Если архитектура нарушает его - она плохая, но если соответствует - то не факт

@yarbersheer8559 2 года назад

Второй раз пересматриваю... Я себя чувствую гуру с длинной бородой, в вязаном свитере с котэ на коленках. Изучаю Golang. В большинстве видео объяснением вызова метода структуры (в го как говорят "классов нет", но какая разница, что говорят, если по сути стуктуры это классы) по адресу является то, что "это быстрее, память не выделяется". И ни один "профи" не смог нормально объяснить, что по сути смысл один: вызов метода по адресу - это Сеттер, а по значению - это геттер (т.к. происходит защита от изменения). Ещё раз люто благодарствую. И за чёткость и за самолёты, для маёвской Души)

@MasterLid 2 года назад

Спасибо за положительную оценку. Но вы что-то путаете. Геттер возвращает то или иное поле в объекте, а сеттер устанавливает значение поля объекта. И геттер и сеттер вызываются у экземпляров объекта. То, что вы называете "метод структуры" в Java/C++/TypeScript называется статическим методом, который один общий для всех экземпляров. Именно поэтому дополнительная память не выделяется. Кстати, статический метод в ООП -- это аналог чистой функции в ФП.

@yarbersheer8559 2 года назад

@@MasterLid Может я просто криво выразился. В Golang обращение к методу экземпляра объекта может быть выполнено по адресу объекта, либо по значению объекта. Если на примере: package main import ( "fmt" ) //Создаём структуру ака "класс" type test struct { TestVal int } // Создаём метод в который передаём копию экземпляра объекта func (t test) testMethod() { t.TestVal = 100000 print(t.TestVal) } // Создаём метод в который передаём адрес экземпляра объекта func (t *test) testMethod2() { t.TestVal = 100000 print(t.TestVal) } func main() { // Создаём экземпляр со значением 11 testVar := test{TestVal: 11} testVar.testMethod() fmt.Println(testVar.TestVal) testVar.testMethod2() fmt.Println(testVar.TestVal) } Вывод будет такой: /*Метод вызванный копией экземпляра объекта внутри себя выдаст 100000, но не изменит этот параметр вне себя - Getter*/ 100000 11 /*Метод вызванный по адресу экземпляра объекта внутри себя выдаст 100000, и изменит это значение у объекта - Setter*/ 100000 100000 Process exiting with code: 0 А статические методы - это в Golang, видимо, просто методы более верхнего уровня или методы интерфейсов... Заранее извиняюсь за все косяки. Я последний раз писал на C++ в 2007м. Сейчас хочется стать бэк-энд разработчиком, по моей аналитике Golang в этом сейчас и в будущем будет лучшим. Изучаю разные курсы и видео.. но там такая каша с терминологией... Структура описанная Вами имеет необходимый уровень абстракции, чтобы я мог понимать "что происходит" и "как надо делать" для реализации нормального ООП. По сути, вы предоставили мне интерфейс класса "язык программирования", который я полиморфлю для Golang

@MasterLid 2 года назад

То, что вы написали, опять же не имеет отношения к геттерам и сеттерам. Если программировали на C++, то должны же помнить указатели! Вот это они и есть. Ну почти. В C++ есть конструкция "передача объекта по ссылке", когда в функцию передается ссылка на экземпляр объекта, а не копия объекта. Только в C++ вместо звездочки используется для этого амперсанд (звездочка в C++ тоже есть, но используется как раз для указателей). Поищите в гуле запрос "С++ передача по ссылке". Вам станет понятно, что имеется в виду в Go. И да, не пытайтесь перекладывать ООП из моего ролика на Go. Если бы Go меня устраивал в реализации ООП-парадигмы, я бы его включил в обзор. Но он меня не устраивает. Поэтому не советую "натягивать сову на глобус". Просто Go про другое, нет там полноценного ООП. То же самое -- пытаться разбирать какой-нибудь функционально-ориентированный ЯП, например, Elixir, с точки зрения ООП. Ну нет там этого, за ненадобностью.

@yarbersheer8559 2 года назад

@@MasterLid Благодарю за пояснения. Про амперсанд и * я помню. В Го & - это "разадресатор" или "разуказатель". Конечно, нет смысла работы с адресной арифметикой в Го. Цель моих изысканий не впихание невпихуемого, а упорядочивание концепций и принципов в голове. Даже если и Го не вполне ООП, станет ли мой код хуже от того, что я буду использовать культуру ООП в нём и применять разные виды экзепляров класса для разных задач с целью обеспечения псевдо-инкапсуляции? На мой взгляд, в итоге, подобное приведёт лишь к более качественной архитектуре моих программ в будущем. В общем и целом, я для себя чётко определил, что при проектировании методов мне будет лучше разделять передачу указателя на экземпляр и экземпляр как мнимые сеттер и геттер, при этом в случае геттера в методе будет разумно применять defer удаления копии при завершения обращения с целью упрощения работы garbage collector. Возможно и скорее всего, я зря так загоняюсь и было бы более эффективно идти дальше и набивать руку на marshall json и RESTful , но здесь я увидел красоту логику, потому и вник, дабы не плодить сомнения холивора "твой полиморфизм не настоящий полиморфизм" и пр. В любом случае, Ваш ролик самый "опытный" из тех, что я видел, включая один из самых популярных @ExtremeCode ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ve3eAhuaF0s.html

@yarbersheer8559 2 года назад

@@MasterLid очевидно, я всё-таки перемудриваю. В документации Go уже есть упоминания о геттерах и сеттерах Getters Go doesn't provide automatic support for getters and setters. There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put Get into the getter's name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will likely be called SetOwner. Both names read well in practice: owner := obj.Owner() if owner != user { obj.SetOwner(user) }

@MasterLid 3 года назад

22.03.2021 вышел, наконец, официальный релиз 1.0 языка Crystal. Если кому интересно, могу сделать краткий обзор на него. По мне так они сильно опоздали с ним. Интерес к Ruby уже исчез, поезд ушел. Но сам язык достаточно интересный, многие вещи сделаны хорошо.

@strash1692 3 года назад

Почему не был упомянут Python?

@MasterLid 3 года назад

Я не особо интересуюсь новостями из мира питона, честно говоря. По принципу "нельзя объять необъятное". То, как сделано ООП в питоне, мне не очень сильно нравится. Crystal смотрел как годную и ООП-красивую альтернативу Go.

@Shakl-e 2 года назад

Упомянули Dart, спасибо) Учитывая популярность Flutter, он сейчас будет очень популярен)

@MasterLid 2 года назад

Да, в Dart очень хорошая реализация ООП! Скажем так, взяли всё хорошее от Java и сделали намного лучше, по-современному. Возможно, сделаю несколько роликов по Dart и Flutter.

@Shakl-e 2 года назад

@@MasterLid Было бы супер. На примере с самолетами все понятно, но вот, когда пишешь программу, то с теми объектами, что встречаются там уже зачастую не так все ясно. Я даже могу не знать, что будет дальше... К примеру мне сейчас нужно создать класс с каким-то свойствами, а в будущем нужно что-то добавить и вроде как эти новые классы по смыслу где-то рядом с созданным уже, но тянет ли тот первый класс на BaseClass для этоц группы объектов или нет уже не особо ясно в большинстве ситуаций, стоит ли делать новый BaseClass и переносить в него с первого объекта свойства тоже сомнительно и вот началась каша. Было бы круто увидеть видео, где вы пишите приложение и там есть немного взаимосвязанного функционала в котором применяются все эти парадигмы ООП и рассказывается, что и почему шаг за шагом. Ваш канал и стиль подачи очень современный и интересный, тянет на миллионник в будущем, удачи!)

@MasterLid 2 года назад

Спасибо за положительную оценку. Что-нибудь постараюсь придумать. А миллионник я вряд ли потяну. Это ж нужно чуть ли не каждую неделю ролики выпускать. Работа не позволит вытворять такое. : ) Но благодарю!

@strash1692 3 года назад

Доброго дня. Спасибо за видео. Вопрос возник в результате просмотра. Что является подобием примесей в Java?

@strash1692 3 года назад

Первое что приходит на ум - множественное наследование интерфейсов и их дефолт методы, но разве это не антипаттерн? Или речь о чём-то другом?

@MasterLid 3 года назад

Подобием примесей в Java являются дефолтные методы в интерфейсах. Вот, например, статья (на английском): opencredo.com/blogs/traits-java-8-default-methods/ В Java, в отличие от других языков программирования, очень медленно и постепенно вводят какие-либо новшества. Связано это с тем, что за время существования Java наработан огромный объем исходного кода, которому крайне желательна обратная совместимость. Многим это не нравится. Мне, например, сильно не хватает дефолтных значений в параметрах функций. Уже давно можно было бы это сделать, но нет. До сих пор вопрос решается переопределением методов.

@strash1692 3 года назад

@@MasterLid Спасибо за ответ. Я так и подумал, что речь возможно про дефолт методы в интерфейсах, т.к. только они, на мой взгляд, близки к реализации примесей. Но меня учили, что дефолт методы введены для возможности расширения интерфейсов без фатальных последствий для написанного кода, и обязательно должны быть переопределены как можно скорее. Не ужели их использование нашло другое применение и это используется в продакшене?

@MasterLid 3 года назад

Лично я не использую. Потому что для меня реализация метода в интерфейсе -- это уже дичь. Интерфейс на то и интерфейс, чтобы просто объявлять методы. Даже наличие констант в нём спорно, хотя и терпимо. Ну вот меня так учили в начале 2000-х. Насчёт других не знаю. Отсутствие настоящих примесей в Java не очень напрягает. Всё решается архитектурными решениями.

@strash1692 3 года назад

Спасибо. Ну да - дичь, с оговоркой что это приемлемо только лишь для особого случая, когда лучше так, чем по другому. А вот про архитектурные решения интересно, могли бы привести примеры? Очень интересно. Сам лишь только с композицией знаком, как с одним из решений.

@lesharper8751 3 года назад

Странно, что не добавили С# в список языков с ООП, т.к там даже получше, чем в Java

@MasterLid 3 года назад

Вполне может быть. Но я стараюсь говорить только о том, о чем имею представление. А с C# я никогда не работал, поэтому не могу ничего рассказать о его достоинствах.

@gospodinkto1224 2 года назад

чет как-то сложновато моментами это все воспринимать ещё в такой монотонно быстрой читке

@MasterLid 2 года назад

Увы, я не профессиональный актёр с поставленным голосом, а программист. Наверное, Михаил Ефремов рассказал бы про ООП гораздо лучше меня! Но поскольку его в наличии нет, можно воспользоваться контролом скорости воспроизведения.

@user-on6zj3yy2q Год назад

@@MasterLid Вы мастер ответов хахахах)

@MaksZhovna 2 года назад

Kiss - keep it short and simple

@MasterLid 2 года назад

Можно я немного позанудствую и сошлюсь на Википедию? А она утверждает, что это именно Keep It Simple Stupid, принцип, утвержденный в ВМС США в 1960 году. Возможно, есть какие-то вторичные толкования, появившиеся намного позже, но первоначальный смысл именно в этом: не надо усложнять то, что можно сделать просто.

@MaksZhovna 2 года назад

@@MasterLid Вы не правы, первый смысл был "keep it short and simple", а "Keep It Simple Stupid" это юмористическая сленговая версия, которая появилась позже, и которую любят форсить программеры, да и смысловой нагрузки первая версия несет больше, тем более для программеров. Все инженеры знают этот принцип, и даже экономисты, и каждый придумывает свою версию)) А в википедии расшифровка этого принципа постоянная меняется, история версий в помощь

@MasterLid 2 года назад

Окей, пусть будет по вашему. Вы оказались даже большей занудой чем я. ; )

@MaksZhovna 2 года назад

@@MasterLid ах-ха, это препод по сопромату виноват))