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

Поділитися
Вставка
  • Опубліковано 24 гру 2024

КОМЕНТАРІ • 50

  • @NewUser78654
    @NewUser78654 2 роки тому

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

    • @MasterLid
      @MasterLid  2 роки тому +2

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

  • @BobberBobston
    @BobberBobston Рік тому

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

  • @vanitokurason8445
    @vanitokurason8445 2 роки тому +1

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

  • @e1.st0rm99
    @e1.st0rm99 3 роки тому +8

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @blackmulthumor
      @blackmulthumor Рік тому

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

  • @ИванСапронов-з8ь
    @ИванСапронов-з8ь 3 роки тому +1

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

  • @azeezbro2731
    @azeezbro2731 3 роки тому +1

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

  • @mitruslatovous6
    @mitruslatovous6 2 роки тому

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

  • @yushchenkoalexey
    @yushchenkoalexey 2 роки тому

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

  • @MasterLid
    @MasterLid  3 роки тому +3

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

    • @strash1692
      @strash1692 3 роки тому +1

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

    • @MasterLid
      @MasterLid  3 роки тому +2

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

  • @blackmulthumor
    @blackmulthumor Рік тому +1

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

  • @АлександрЛебедев-ь4ю4р

    Четко

  • @yarbersheer8559
    @yarbersheer8559 3 роки тому +2

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

    • @MasterLid
      @MasterLid  3 роки тому

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

    • @yarbersheer8559
      @yarbersheer8559 3 роки тому

      @@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
      @MasterLid  3 роки тому +1

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

    • @yarbersheer8559
      @yarbersheer8559 3 роки тому

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

    • @yarbersheer8559
      @yarbersheer8559 3 роки тому

      @@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)
      }

  • @Shakl-e
    @Shakl-e 3 роки тому +1

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @Shakl-e
      @Shakl-e 3 роки тому +1

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

    • @MasterLid
      @MasterLid  3 роки тому

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

  • @dodokwak
    @dodokwak 3 роки тому

    отлично.

  • @0xsadcat92
    @0xsadcat92 Рік тому

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

  • @strash1692
    @strash1692 3 роки тому +1

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

    • @strash1692
      @strash1692 3 роки тому

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @strash1692
      @strash1692 3 роки тому

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @strash1692
      @strash1692 3 роки тому

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

  • @lesharper8751
    @lesharper8751 3 роки тому +2

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

  • @gospodinkto1224
    @gospodinkto1224 3 роки тому +3

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @BobberBobston
      @BobberBobston Рік тому

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

  • @MaksZhovna
    @MaksZhovna 3 роки тому +1

    Kiss - keep it short and simple

    • @MasterLid
      @MasterLid  3 роки тому

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

    • @MaksZhovna
      @MaksZhovna 3 роки тому +1

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

    • @MasterLid
      @MasterLid  3 роки тому +1

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

    • @MaksZhovna
      @MaksZhovna 3 роки тому +1

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

  • @romanmotovilov129
    @romanmotovilov129 3 роки тому

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