В плане поддержки ООП в PHP не соглашусь. Первое, над чем стоит подумать - это смысл ООП. ООП это про объекты. А объекты (в отличии от тех же функций), это то, что должно храниться в памяти. Запомните эту идею. Функция - ничего не храним в памяти. А объект - инстанцировались от класса , и храним его, работаем с ним, уничтожаем его и т.д. Языки C++ JAVA C# и т.д. в общем смысле десктопные. Да у них может быть широкое применение, но они не сильно распространены в вебе. И на JAVA и C# пишут сайты, но это другое. Там другой подход, в отличии от PHP. Так чем же плох PHP в плане ООП? Время жизни программы ограничено. В 90% случаев мы точно знаем предельное время выполнения скрипта (директива в php.ini). В десктопных программах время зачастую не ограничено. Запустили и работает, пока не закроем. И объекты существуют. То есть в PHP предельное время жизни объекта ограничено, что, с точки зрения ООП не очень хорошо. Далее - синтаксис. Методы называют функциями. Статические классы (как в C#) отсутствуют, в результате чего базовый паттерн синглтон (не забываем про магические методы, клонирование и т.д.) реализуется не самым красивым образом. Есть глобальные переменные, которые в неумелых руках нарушают инкапсуляцию. Отсутствует строгая типизация до php 7, позже появилась, но редко применяется. Аргументы метода могут быть любые, нужны дополнительные проверки - код. Присутствует ключевое слово self, абсолютно не нужное (смотрим на C#). Нет чистых геттеров и сеттеров (смотрим на C#) - есть магические методы. После C# PHP - это не ООП. Это ООП сведенный до базовых возможностей. Также часто вижу использование ООП в функциональном стиле, т.е. повсеместное использование статических методов.
Боже, какое феерическое занудство, причём мимо кассы. ООП -- это не про то, как долго объект находится в памяти, и не про то, как называется метод. А про архитектуру. В PHP с ООП-ориентированной архитектурой всё в порядке. Не блестяще, не искромётно гениально, но очень даже работоспособно для продакшена. И при чём тут C#? Нравится C# -- программируйте на нём. К чему этот токсичный негатив?
Очень круто! Приятно, что без воды и реально по существу, хотя допускаю, что чтобы насладиться этим четким роликом, надо перед ним где-то посмотреть "водяные" невнятные ролики. Классно, что еще вы шутите с серьезным лицом на протяжение ролика (здесь: про американские глубокомысленные акронимы). Это улучшает потребление и обработку информации моим мозгом
Идеальная абстракция разказчика! Всё продумано до мелочей: очки скрывают глаза, шляпа - причёску, цвета одежды монохромны. Образ неброский, но очень запоминающийся. Минимум артикуляции, при этом очень чёткая дикция. Никаких телодвижений, рука на столе даже не шелохнулась! Ничего не отвлекает от усвоения материала. Создаётся впечатление, что перед тобой "андроид" (в хорошем смысле). Впадаешь в лёгкое состояние транса, и в фоновом режиме информация пишется сразу в подкорку. Гениальная подача. Вы на 100% перфекционист. Снимаю шляпу! Подписываюсь и иду смотерть все Ваши ролики. Уже Ваш фанат. Спасибо за труд
Спасибо. Всё просто и понятно. Почему-то вспомнил, как я долго врубался в ООП. Проблема была в том, что подсознательно ожидал чего-то сверх сложного, а на самом деле всё было очень просто. Это и вводило в ступор.
Спасибо за позитивную оценку. Особенность ООП в том, что данная парадигма повторяет принцип человеческого мышления. Мы мыслим абстракциями, и ООП тоже. Поэтому на самом деле это очень простая в понимании технология. В отличие от ФП. ; )
Та же история у меня была) И не только с классами). Мне так просто некоторые темы давались, что я был уверен, что я их раскрыл не полностью и искал больше инфы.
22.03.2021 вышел, наконец, официальный релиз 1.0 языка Crystal. Если кому интересно, могу сделать краткий обзор на него. По мне так они сильно опоздали с ним. Интерес к Ruby уже исчез, поезд ушел. Но сам язык достаточно интересный, многие вещи сделаны хорошо.
Я не особо интересуюсь новостями из мира питона, честно говоря. По принципу "нельзя объять необъятное". То, как сделано ООП в питоне, мне не очень сильно нравится. Crystal смотрел как годную и ООП-красивую альтернативу Go.
Второй раз пересматриваю... Я себя чувствую гуру с длинной бородой, в вязаном свитере с котэ на коленках. Изучаю Golang. В большинстве видео объяснением вызова метода структуры (в го как говорят "классов нет", но какая разница, что говорят, если по сути стуктуры это классы) по адресу является то, что "это быстрее, память не выделяется". И ни один "профи" не смог нормально объяснить, что по сути смысл один: вызов метода по адресу - это Сеттер, а по значению - это геттер (т.к. происходит защита от изменения). Ещё раз люто благодарствую. И за чёткость и за самолёты, для маёвской Души)
Спасибо за положительную оценку. Но вы что-то путаете. Геттер возвращает то или иное поле в объекте, а сеттер устанавливает значение поля объекта. И геттер и сеттер вызываются у экземпляров объекта. То, что вы называете "метод структуры" в Java/C++/TypeScript называется статическим методом, который один общий для всех экземпляров. Именно поэтому дополнительная память не выделяется. Кстати, статический метод в ООП -- это аналог чистой функции в ФП.
@@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
То, что вы написали, опять же не имеет отношения к геттерам и сеттерам. Если программировали на C++, то должны же помнить указатели! Вот это они и есть. Ну почти. В C++ есть конструкция "передача объекта по ссылке", когда в функцию передается ссылка на экземпляр объекта, а не копия объекта. Только в C++ вместо звездочки используется для этого амперсанд (звездочка в C++ тоже есть, но используется как раз для указателей). Поищите в гуле запрос "С++ передача по ссылке". Вам станет понятно, что имеется в виду в Go. И да, не пытайтесь перекладывать ООП из моего ролика на Go. Если бы Go меня устраивал в реализации ООП-парадигмы, я бы его включил в обзор. Но он меня не устраивает. Поэтому не советую "натягивать сову на глобус". Просто Go про другое, нет там полноценного ООП. То же самое -- пытаться разбирать какой-нибудь функционально-ориентированный ЯП, например, Elixir, с точки зрения ООП. Ну нет там этого, за ненадобностью.
@@MasterLid Благодарю за пояснения. Про амперсанд и * я помню. В Го & - это "разадресатор" или "разуказатель". Конечно, нет смысла работы с адресной арифметикой в Го. Цель моих изысканий не впихание невпихуемого, а упорядочивание концепций и принципов в голове. Даже если и Го не вполне ООП, станет ли мой код хуже от того, что я буду использовать культуру ООП в нём и применять разные виды экзепляров класса для разных задач с целью обеспечения псевдо-инкапсуляции? На мой взгляд, в итоге, подобное приведёт лишь к более качественной архитектуре моих программ в будущем. В общем и целом, я для себя чётко определил, что при проектировании методов мне будет лучше разделять передачу указателя на экземпляр и экземпляр как мнимые сеттер и геттер, при этом в случае геттера в методе будет разумно применять defer удаления копии при завершения обращения с целью упрощения работы garbage collector. Возможно и скорее всего, я зря так загоняюсь и было бы более эффективно идти дальше и набивать руку на marshall json и RESTful , но здесь я увидел красоту логику, потому и вник, дабы не плодить сомнения холивора "твой полиморфизм не настоящий полиморфизм" и пр. В любом случае, Ваш ролик самый "опытный" из тех, что я видел, включая один из самых популярных @ExtremeCode ua-cam.com/video/ve3eAhuaF0s/v-deo.html
@@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) }
Да, в Dart очень хорошая реализация ООП! Скажем так, взяли всё хорошее от Java и сделали намного лучше, по-современному. Возможно, сделаю несколько роликов по Dart и Flutter.
@@MasterLid Было бы супер. На примере с самолетами все понятно, но вот, когда пишешь программу, то с теми объектами, что встречаются там уже зачастую не так все ясно. Я даже могу не знать, что будет дальше... К примеру мне сейчас нужно создать класс с каким-то свойствами, а в будущем нужно что-то добавить и вроде как эти новые классы по смыслу где-то рядом с созданным уже, но тянет ли тот первый класс на BaseClass для этоц группы объектов или нет уже не особо ясно в большинстве ситуаций, стоит ли делать новый BaseClass и переносить в него с первого объекта свойства тоже сомнительно и вот началась каша. Было бы круто увидеть видео, где вы пишите приложение и там есть немного взаимосвязанного функционала в котором применяются все эти парадигмы ООП и рассказывается, что и почему шаг за шагом. Ваш канал и стиль подачи очень современный и интересный, тянет на миллионник в будущем, удачи!)
Спасибо за положительную оценку. Что-нибудь постараюсь придумать. А миллионник я вряд ли потяну. Это ж нужно чуть ли не каждую неделю ролики выпускать. Работа не позволит вытворять такое. : ) Но благодарю!
Подобием примесей в Java являются дефолтные методы в интерфейсах. Вот, например, статья (на английском): opencredo.com/blogs/traits-java-8-default-methods/ В Java, в отличие от других языков программирования, очень медленно и постепенно вводят какие-либо новшества. Связано это с тем, что за время существования Java наработан огромный объем исходного кода, которому крайне желательна обратная совместимость. Многим это не нравится. Мне, например, сильно не хватает дефолтных значений в параметрах функций. Уже давно можно было бы это сделать, но нет. До сих пор вопрос решается переопределением методов.
@@MasterLid Спасибо за ответ. Я так и подумал, что речь возможно про дефолт методы в интерфейсах, т.к. только они, на мой взгляд, близки к реализации примесей. Но меня учили, что дефолт методы введены для возможности расширения интерфейсов без фатальных последствий для написанного кода, и обязательно должны быть переопределены как можно скорее. Не ужели их использование нашло другое применение и это используется в продакшене?
Лично я не использую. Потому что для меня реализация метода в интерфейсе -- это уже дичь. Интерфейс на то и интерфейс, чтобы просто объявлять методы. Даже наличие констант в нём спорно, хотя и терпимо. Ну вот меня так учили в начале 2000-х. Насчёт других не знаю. Отсутствие настоящих примесей в Java не очень напрягает. Всё решается архитектурными решениями.
Спасибо. Ну да - дичь, с оговоркой что это приемлемо только лишь для особого случая, когда лучше так, чем по другому. А вот про архитектурные решения интересно, могли бы привести примеры? Очень интересно. Сам лишь только с композицией знаком, как с одним из решений.
Вполне может быть. Но я стараюсь говорить только о том, о чем имею представление. А с C# я никогда не работал, поэтому не могу ничего рассказать о его достоинствах.
Увы, я не профессиональный актёр с поставленным голосом, а программист. Наверное, Михаил Ефремов рассказал бы про ООП гораздо лучше меня! Но поскольку его в наличии нет, можно воспользоваться контролом скорости воспроизведения.
Можно я немного позанудствую и сошлюсь на Википедию? А она утверждает, что это именно Keep It Simple Stupid, принцип, утвержденный в ВМС США в 1960 году. Возможно, есть какие-то вторичные толкования, появившиеся намного позже, но первоначальный смысл именно в этом: не надо усложнять то, что можно сделать просто.
@@MasterLid Вы не правы, первый смысл был "keep it short and simple", а "Keep It Simple Stupid" это юмористическая сленговая версия, которая появилась позже, и которую любят форсить программеры, да и смысловой нагрузки первая версия несет больше, тем более для программеров. Все инженеры знают этот принцип, и даже экономисты, и каждый придумывает свою версию)) А в википедии расшифровка этого принципа постоянная меняется, история версий в помощь
В плане поддержки ООП в PHP не соглашусь.
Первое, над чем стоит подумать - это смысл ООП. ООП это про объекты. А объекты (в отличии от тех же функций), это то, что должно храниться в памяти.
Запомните эту идею. Функция - ничего не храним в памяти. А объект - инстанцировались от класса , и храним его, работаем с ним, уничтожаем его и т.д.
Языки C++ JAVA C# и т.д. в общем смысле десктопные. Да у них может быть широкое применение, но они не сильно распространены в вебе.
И на JAVA и C# пишут сайты, но это другое. Там другой подход, в отличии от PHP.
Так чем же плох PHP в плане ООП? Время жизни программы ограничено.
В 90% случаев мы точно знаем предельное время выполнения скрипта (директива в php.ini). В десктопных программах время зачастую не ограничено. Запустили и работает, пока не закроем. И объекты существуют.
То есть в PHP предельное время жизни объекта ограничено, что, с точки зрения ООП не очень хорошо.
Далее - синтаксис.
Методы называют функциями.
Статические классы (как в C#) отсутствуют, в результате чего базовый паттерн синглтон (не забываем про магические методы, клонирование и т.д.) реализуется не самым красивым образом.
Есть глобальные переменные, которые в неумелых руках нарушают инкапсуляцию.
Отсутствует строгая типизация до php 7, позже появилась, но редко применяется. Аргументы метода могут быть любые, нужны дополнительные проверки - код.
Присутствует ключевое слово self, абсолютно не нужное (смотрим на C#).
Нет чистых геттеров и сеттеров (смотрим на C#) - есть магические методы.
После C# PHP - это не ООП. Это ООП сведенный до базовых возможностей.
Также часто вижу использование ООП в функциональном стиле, т.е. повсеместное использование статических методов.
Боже, какое феерическое занудство, причём мимо кассы.
ООП -- это не про то, как долго объект находится в памяти, и не про то, как называется метод. А про архитектуру. В PHP с ООП-ориентированной архитектурой всё в порядке. Не блестяще, не искромётно гениально, но очень даже работоспособно для продакшена.
И при чём тут C#? Нравится C# -- программируйте на нём. К чему этот токсичный негатив?
Очень круто! Приятно, что без воды и реально по существу, хотя допускаю, что чтобы насладиться этим четким роликом, надо перед ним где-то посмотреть "водяные" невнятные ролики. Классно, что еще вы шутите с серьезным лицом на протяжение ролика (здесь: про американские глубокомысленные акронимы). Это улучшает потребление и обработку информации моим мозгом
Идеальная абстракция разказчика! Всё продумано до мелочей: очки скрывают глаза, шляпа - причёску, цвета одежды монохромны. Образ неброский, но очень запоминающийся. Минимум артикуляции, при этом очень чёткая дикция. Никаких телодвижений, рука на столе даже не шелохнулась! Ничего не отвлекает от усвоения материала. Создаётся впечатление, что перед тобой "андроид" (в хорошем смысле). Впадаешь в лёгкое состояние транса, и в фоновом режиме информация пишется сразу в подкорку. Гениальная подача. Вы на 100% перфекционист. Снимаю шляпу! Подписываюсь и иду смотерть все Ваши ролики. Уже Ваш фанат. Спасибо за труд
Спасибо. Всё просто и понятно. Почему-то вспомнил, как я долго врубался в ООП. Проблема была в том, что подсознательно ожидал чего-то сверх сложного, а на самом деле всё было очень просто. Это и вводило в ступор.
Спасибо за позитивную оценку.
Особенность ООП в том, что данная парадигма повторяет принцип человеческого мышления. Мы мыслим абстракциями, и ООП тоже. Поэтому на самом деле это очень простая в понимании технология. В отличие от ФП. ; )
Та же история у меня была) И не только с классами). Мне так просто некоторые темы давались, что я был уверен, что я их раскрыл не полностью и искал больше инфы.
Спасибо большое! Очень ждём новых видео.
Классно, все понятно и без воды
Всё хорошо, полёт нормальный (с)
Очень крутое видео, большое спасибо!
22.03.2021 вышел, наконец, официальный релиз 1.0 языка Crystal. Если кому интересно, могу сделать краткий обзор на него.
По мне так они сильно опоздали с ним. Интерес к Ruby уже исчез, поезд ушел. Но сам язык достаточно интересный, многие вещи сделаны хорошо.
Почему не был упомянут Python?
Я не особо интересуюсь новостями из мира питона, честно говоря. По принципу "нельзя объять необъятное". То, как сделано ООП в питоне, мне не очень сильно нравится. Crystal смотрел как годную и ООП-красивую альтернативу Go.
Вилли Вонка сменил профессию) И не зря, если судить по качеству уроков!
Четко
Второй раз пересматриваю... Я себя чувствую гуру с длинной бородой, в вязаном свитере с котэ на коленках.
Изучаю Golang. В большинстве видео объяснением вызова метода структуры (в го как говорят "классов нет", но какая разница, что говорят, если по сути стуктуры это классы) по адресу является то, что "это быстрее, память не выделяется". И ни один "профи" не смог нормально объяснить, что по сути смысл один: вызов метода по адресу - это Сеттер, а по значению - это геттер (т.к. происходит защита от изменения).
Ещё раз люто благодарствую. И за чёткость и за самолёты, для маёвской Души)
Спасибо за положительную оценку. Но вы что-то путаете. Геттер возвращает то или иное поле в объекте, а сеттер устанавливает значение поля объекта. И геттер и сеттер вызываются у экземпляров объекта. То, что вы называете "метод структуры" в Java/C++/TypeScript называется статическим методом, который один общий для всех экземпляров. Именно поэтому дополнительная память не выделяется.
Кстати, статический метод в ООП -- это аналог чистой функции в ФП.
@@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
То, что вы написали, опять же не имеет отношения к геттерам и сеттерам. Если программировали на C++, то должны же помнить указатели! Вот это они и есть. Ну почти. В C++ есть конструкция "передача объекта по ссылке", когда в функцию передается ссылка на экземпляр объекта, а не копия объекта. Только в C++ вместо звездочки используется для этого амперсанд (звездочка в C++ тоже есть, но используется как раз для указателей). Поищите в гуле запрос "С++ передача по ссылке". Вам станет понятно, что имеется в виду в Go.
И да, не пытайтесь перекладывать ООП из моего ролика на Go. Если бы Go меня устраивал в реализации ООП-парадигмы, я бы его включил в обзор. Но он меня не устраивает. Поэтому не советую "натягивать сову на глобус". Просто Go про другое, нет там полноценного ООП. То же самое -- пытаться разбирать какой-нибудь функционально-ориентированный ЯП, например, Elixir, с точки зрения ООП. Ну нет там этого, за ненадобностью.
@@MasterLid Благодарю за пояснения.
Про амперсанд и * я помню. В Го & - это "разадресатор" или "разуказатель". Конечно, нет смысла работы с адресной арифметикой в Го.
Цель моих изысканий не впихание невпихуемого, а упорядочивание концепций и принципов в голове.
Даже если и Го не вполне ООП, станет ли мой код хуже от того, что я буду использовать культуру ООП в нём и применять разные виды экзепляров класса для разных задач с целью обеспечения псевдо-инкапсуляции?
На мой взгляд, в итоге, подобное приведёт лишь к более качественной архитектуре моих программ в будущем.
В общем и целом, я для себя чётко определил, что при проектировании методов мне будет лучше разделять передачу указателя на экземпляр и экземпляр как мнимые сеттер и геттер, при этом в случае геттера в методе будет разумно применять defer удаления копии при завершения обращения с целью упрощения работы garbage collector.
Возможно и скорее всего, я зря так загоняюсь и было бы более эффективно идти дальше и набивать руку на marshall json и RESTful , но здесь я увидел красоту логику, потому и вник, дабы не плодить сомнения холивора "твой полиморфизм не настоящий полиморфизм" и пр.
В любом случае, Ваш ролик самый "опытный" из тех, что я видел, включая один из самых популярных @ExtremeCode ua-cam.com/video/ve3eAhuaF0s/v-deo.html
@@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)
}
Упомянули Dart, спасибо) Учитывая популярность Flutter, он сейчас будет очень популярен)
Да, в Dart очень хорошая реализация ООП! Скажем так, взяли всё хорошее от Java и сделали намного лучше, по-современному.
Возможно, сделаю несколько роликов по Dart и Flutter.
@@MasterLid Было бы супер. На примере с самолетами все понятно, но вот, когда пишешь программу, то с теми объектами, что встречаются там уже зачастую не так все ясно. Я даже могу не знать, что будет дальше... К примеру мне сейчас нужно создать класс с каким-то свойствами, а в будущем нужно что-то добавить и вроде как эти новые классы по смыслу где-то рядом с созданным уже, но тянет ли тот первый класс на BaseClass для этоц группы объектов или нет уже не особо ясно в большинстве ситуаций, стоит ли делать новый BaseClass и переносить в него с первого объекта свойства тоже сомнительно и вот началась каша.
Было бы круто увидеть видео, где вы пишите приложение и там есть немного взаимосвязанного функционала в котором применяются все эти парадигмы ООП и рассказывается, что и почему шаг за шагом.
Ваш канал и стиль подачи очень современный и интересный, тянет на миллионник в будущем, удачи!)
Спасибо за положительную оценку. Что-нибудь постараюсь придумать.
А миллионник я вряд ли потяну. Это ж нужно чуть ли не каждую неделю ролики выпускать. Работа не позволит вытворять такое. : ) Но благодарю!
отлично.
В команте на счет SOLID считаем его как следствие. Если архитектура нарушает его - она плохая, но если соответствует - то не факт
Доброго дня. Спасибо за видео. Вопрос возник в результате просмотра.
Что является подобием примесей в Java?
Первое что приходит на ум - множественное наследование интерфейсов и их дефолт методы, но разве это не антипаттерн? Или речь о чём-то другом?
Подобием примесей в Java являются дефолтные методы в интерфейсах. Вот, например, статья (на английском): opencredo.com/blogs/traits-java-8-default-methods/
В Java, в отличие от других языков программирования, очень медленно и постепенно вводят какие-либо новшества. Связано это с тем, что за время существования Java наработан огромный объем исходного кода, которому крайне желательна обратная совместимость. Многим это не нравится. Мне, например, сильно не хватает дефолтных значений в параметрах функций. Уже давно можно было бы это сделать, но нет. До сих пор вопрос решается переопределением методов.
@@MasterLid Спасибо за ответ. Я так и подумал, что речь возможно про дефолт методы в интерфейсах, т.к. только они, на мой взгляд, близки к реализации примесей. Но меня учили, что дефолт методы введены для возможности расширения интерфейсов без фатальных последствий для написанного кода, и обязательно должны быть переопределены как можно скорее. Не ужели их использование нашло другое применение и это используется в продакшене?
Лично я не использую. Потому что для меня реализация метода в интерфейсе -- это уже дичь. Интерфейс на то и интерфейс, чтобы просто объявлять методы. Даже наличие констант в нём спорно, хотя и терпимо. Ну вот меня так учили в начале 2000-х.
Насчёт других не знаю. Отсутствие настоящих примесей в Java не очень напрягает. Всё решается архитектурными решениями.
Спасибо. Ну да - дичь, с оговоркой что это приемлемо только лишь для особого случая, когда лучше так, чем по другому. А вот про архитектурные решения интересно, могли бы привести примеры? Очень интересно. Сам лишь только с композицией знаком, как с одним из решений.
Странно, что не добавили С# в список языков с ООП, т.к там даже получше, чем в Java
Вполне может быть. Но я стараюсь говорить только о том, о чем имею представление. А с C# я никогда не работал, поэтому не могу ничего рассказать о его достоинствах.
чет как-то сложновато моментами это все воспринимать ещё в такой монотонно быстрой читке
Увы, я не профессиональный актёр с поставленным голосом, а программист.
Наверное, Михаил Ефремов рассказал бы про ООП гораздо лучше меня! Но поскольку его в наличии нет, можно воспользоваться контролом скорости воспроизведения.
@@MasterLid Вы мастер ответов хахахах)
Kiss - keep it short and simple
Можно я немного позанудствую и сошлюсь на Википедию?
А она утверждает, что это именно Keep It Simple Stupid, принцип, утвержденный в ВМС США в 1960 году. Возможно, есть какие-то вторичные толкования, появившиеся намного позже, но первоначальный смысл именно в этом: не надо усложнять то, что можно сделать просто.
@@MasterLid Вы не правы, первый смысл был "keep it short and simple", а "Keep It Simple Stupid" это юмористическая сленговая версия, которая появилась позже, и которую любят форсить программеры, да и смысловой нагрузки первая версия несет больше, тем более для программеров. Все инженеры знают этот принцип, и даже экономисты, и каждый придумывает свою версию)) А в википедии расшифровка этого принципа постоянная меняется, история версий в помощь
Окей, пусть будет по вашему. Вы оказались даже большей занудой чем я. ; )
@@MasterLid ах-ха, это препод по сопромату виноват))
Спасибо большое! Очень ждём новых видео.