Что нужно знать про ООП

#soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...

[@МаксимАлексеев-ч4й]

Добрый день. Читали ли вы книгу Гради Буча "Объектно ориентированный анализ и проектирование"? И если да, что вы о ней думаете? Вообще, было бы интересно послушать про книги, которые вы читали, и какие из них можете посоветовать. Либо в одном видео, либо можно было бы плейлист сделать с обзором каждой книги. Ребят, если согласны с предложением про книги - палец в вверх пожалуйста)

[@andreyzhukov2821]

Лайк конечно же поставил. Но мне всё равно не понятно. Тем более другому человеку объяснить бы не смог. Было бы хорошим дополнением добавить ссылку на практическое применение или показать скрины, что это и для чего. Тема ООП довольно популярная, на мой взгляд необходимо выпустить ещё видео на эту тему, но с практической точки зрения.

[@dimanrubik]

Я лучше стал понимать ООП, когда начал писать на Java. Она более удобна для старта изучения ООП, чем C++.

[@staschehovskih1376]

До просмотра видео я думал что начинаю немного разбираться, после просмотра я понял что не разбираюсь и вообще запутался)))

[@0imax]

Мне понравились лекции Сергея Немчинского про основы Java, там он рассказывает в том числе про ООП, причём очень доходчиво.

[@p588e]

UML тебе в помощь. Уяснить ООП = классическое математическое образование + UML

[@khatuntsovmikhail6223]

фишка в том, что это объяснение для тех кто уже понимает в ООП.

[@LordAlanttt]

Согласен, что не надо лезть в объекты через гетеры и сетеры, я делаю все переменные публичными и лезу к ним напрямую на чтение 😏😏😏

[@dimon.digital]

🤩

[@Nonstop4ik]

@@dimon.digital Object.__dict__ ЛЕЗУ И ВЫ МЕНЯ НЕ ОСТАНОВИТЕ

[@DronMC19]

Благодарю за контент. Вроде знал уже некоторый материал по ООП, вроде и писал по ООП, да и React в частности требует писать именно по такому подходу, но ты как-то это структурировал так, что теперь все выглядит... Логично. Мой поклон.

[@gubatenkov]

Реакт 2021 года и ООП это что-то новое)

[@TheOneeightytwo]

даа, Серёга. зашел с целью узнать что же мне нужно знать о ООП. ушел ни с чем. рано. Серёга - это я.

[@alexeyveseliev106]

Ну почему. Сказано же - разделение ответственности в программе нужно знать, глобально. Есть отсылка к книге. Get и set зло.

[@танунахепта]

@@alexeyveseliev106 Ага..а ещё есть те кто МК программирует. Там то, разница есть. Всё равно не очень понятно. Ну так...в общем.

[@alexeyveseliev106]

@@танунахепта Я как раз МК в основном и программирую )

[@cultofsogga5863]

@@igork8433 python

[@0imax]

@@танунахепта в МК с ООП немножко сложно, всё-таки памяти намного меньше и есть места, критичные к производительности. Из моего опыта, ООП в МК ограничивается созданием статических классов, т.е. просто разделением областей видимости. По крайней мере я не пользуюсь ни наследованием, ни полиморфизмом в МК - не попадается настолько сложных задач. В той же Ардуино (не к ночи помянуто будет) ООП как бы есть, но это просто разделение пространства имён с помощью статических классов. Давать какие-то мощные инструменты ардуино-писателям не нужно, они и так спокойно стреляют себе в ногу :)

[@alexeyveseliev106]

Думаю Null vs Empty объекты Vs Exceptions это хорошая тема для холивара

[@0imax]

Просто надо применять то, что лучше подходит по смыслу, и никаких холиваров не будет))

[@ДмитрийБеляев-ъ1з]

В ФП как то обходятся и без Null (привет монада Option/Maybe) и без Exceptions (монада Result) и живут прекрасно, и ошибок меньше в коде. У исходного ООП те же идеи, что и у ФП, пусть и не доказанные математически, но призванные упростить код и сделать его стабильнее. Вот только пришли процедурные обезьяны, и пошло... try-catch, if(x != null) и прочая жесть, делающая софт сложным и забагованным...

[@serhiis_]

@@ДмитрийБеляев-ъ1з try-catch насовали в джава везде там где надо и не надо. и в программе где 2+2 сложить нужно обязательно писать try-catch просто потому что так требует компилятор. Я утритую с примером. Но попрбуйте засетить в json любое значение без try-catch !!! Не получилось не компилит? Скажите спасибо ООП и С++ откуда это пошло собсвенно. Благо в objc от GC и try-catch мусора отошли и это считается быдлокодом. Надеюсь последний год пишу под андроид -мусорку. Такой боли я в аду не видал. Каждую строку писать try-catch и если не напишешь - компилятор просто не компилирует! Бред полнейший!!! А еще там есть JSON.NULL который НЕ РАВНО null. Очень классно да? Сервер прислал вместо строки null и он спарсился в JSON.NULL и его отловить можно только так if (str!=null || str != JSON.NULL) Очень удобно правда? а на сервере у них база null вставляет и это считается нормальное поведение. Поэтому мне во всей программе вместо одной проверки нудно писать ДВОЙНУЮ! СПАСИБО ООП!!! Я БАЛДЕЮ!

[@serhiis_]

@@ДмитрийБеляев-ъ1з и в джава ввести слово var религия не позволяет !!! Да в какойто там 10 или 11 джаве ввели слово "вар". Андроид студия если что на 7 джаве и кое-как на 8-ю переходит с большими костылями.

[@ДмитрийБеляев-ъ1з]

@@serhiis_ в Ваших словах чувствуется очень много боли от инструмента, с которым Вам приходится работать... Я не особо силен в jvm мире, но неужели нельзя перейти на котлин? Или он унаследовал все эти проблемы?

[@hotis8]

Спасибо! Весьма познавательно. Однако начиная с 0:57 и 1:25, очень ждал когда же откроют секрет, как начать думать в объектно-ориентированном стиле и проектировать тоже. Лишь один намёк про ответственности, не очень раскрывает "как же?". Более того он не совсем верно ИМХО изложен. У одного англоговорящего автора, не помню кто, слово "ответственность" заменено на "поведение". Т.е. при проектировании системы думайте о её поведении и задачах, которые должны быть решены, а уже потом о классах которые будут наделены этим поведением. Жду новое видео о том, как же всё таки начать думать в стиле ООП с наглядными примерами, в купе пары паттернов, например observer. Потому одно дело понимать как думать, другое видеть это в коде. Может я ошибаюсь и опыта у меня не много, но пока для меня это, как у школьника правила русского языка знает, а пишет всё равно с ошибками. :)

[@aammssaamm]

Так вы школьник?

[@xmelsky]

Спасибо Соер! Мега инфа, очень полезно, как раз в тему перед первым проектом на ООП

[@dmitriy1129]

как по мне, поймать null reference exception и отследить его в stack trace гораздо проще, чем искать причину появления "пустого" объекта. я про .NET если что говорю.

[@0imax]

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

[@serhiis_]

@@0imax не знаю как в шарпе, но в любом другом языке использовать вместо Null обьект как раз наоборот приводит к падению прложения. В той же java есть json.Null который != null и если вызвать каст или метод обьекта просто упадет приложение. В Objc тоже самое вызов любого метода NSNull приводет к падению, но если мы к null вызовем любой метод - то это норм и падения не будет. Так заложено в языке что вызов метода null ссылки ни чего не делает и это не ошибка. Поэтому возвращать обьект который на вызов любого метода приводит к падению приложения - это дополнительный костыль в свой проект. Тем более ни в одном языке Null != null . Так что задумайтесь! Вы даже проверить нормально его не можете о чем речь? Нужно проверять так Java Object.equials(JSON.NULL, null) // JSON.NULL != null если что!!! objc myObj == (id)NSNull || myObj == null Очень удобно правда? Зачем делать такие костыли? И вы любители писать try-catch в каждой строчке??? Ну удачи тогда любители боли try-catch нельзя писать один на всю программу если вы не знали. Это прервет все 1000 функций в цепочке. Вот каждую строчку пишите try-catch - только так вы не сломаете следующую операцию

[@serhiis_]

@@0imax try-catch использовать в мобильном приложении вообще плохая идея. Я в objc такое ни когда не встречал. А вот в андроиде извращенцы, там системные классы требуют писать try-catch даже если я уверен что исключение в принципе не возможно. Вполне ясно почему все так ненавидят джава и переходят на котлин. Ох уж эти try-catch в методе set json-а. И не обьединишь ведь все в один try-catch. Если один параметр по какой-то причине не засетился это не повод к тому что все остальные 100 параметров нужно прерывать. Как же весело писать try-catch 100 раз что бы засетить 100 параметров json-а в джава((( Жизнь-боль! ООП - Г0вно

[@0imax]

@@serhiis_ не знаю про какой "любой другой" язык вы говорите, но если вместо объекта в переменной лежит null, то при попытке вызвать любой его метод вылезет npe. В той же джаве Integer по умолчанию null, и любой анбоксинг вылетит с npe. Посмотрите паттерн Null Object - он как раз для того, чтобы НЕ падало с npe. Что же до try-catch, так это вина не джавы, а тех, кто заставляет вас писать этот грёбаный try-catch. Ну и насчёт того, что нельзя обойтись одним общим try-catch - так это смотря о чём мы говорим. В энтерпрайз это стандартный подход - ловить исключения наверху и не обмазывать этим весь код. Исключение - работа с ресурсами и вызов методов с чекед эксепшн - тут никуда не денешься. Кстати, после джавы никто чекед эксепшн не делал - все быстро поняли, какая это задница. Так что да, жизнь боль, только ООП тут не виновато ;)

[@serhiis_]

@@0imax исключения придумали в С++. ВОт Страуструп виноват. Джава взяли из плюсов все самое худшее, а андроид СДК сделали исключения в каждую строчку! И не путайте серверную простую консольку, которая обычный текст выводит и не сложнее программы 2+2. И андроид приложения где в каждом классе ипользуется как минимум 3 потока.

[@lavcoder]

Навел меня на выступление Бугаенко! Спасибо! Делись и дальше подобными ссылками с людьми, я продвинулся вперед в понимании...

[@АлексДронго-х3к]

Если бы еще это видео подкрепить каким ни будь не большим (детским), понятным примером, да еще и в MVVM, тогда бы было бы вообще славно.

[@khatuntsovmikhail6223]

всё четко. несоглачен на счет геттеров и сеттеров удобная вещь в плане разделения отвественности для полей (C#), главное не увлекаться добавляя слишком много логики туда. ну а для новичков всё просто садитесь и пишите своё приложение: практика поможет.

[@TMSxYouT]

Насчёт пустых объектов, думаю так в общем утверждать что это лучшее чем Null, я бы не стал, тут масса нюансов , например посмотрите stackoverflow.com/questions/1628434/null-objects-vs-empty-objects

[@S0ERDEVS]

Нюансы есть всегда, но многие даже не знают о том, что для null есть альтернативне стратегии.

[@rewlads]

Optional -- наилучшее

[@wylysypydystyshky]

Сравнить произвольное число с нулём можно. Сравнить строку с пустой строкой можно. Но сравнение числа или строки с null или undefined даёт неочевидный результат. Имхо. Ещё более странным выглядит написать свою функцию для сравнения, в которой один из аргументов может быть null. Получаем велосипед.

[@kirill4531]

Я ждал когда автор затронет важнейший нюанс объектов как элементов композиции: Автор книги Clean Code Боб говорит что важно разделять объекты как структуры данных structs и объекты обладающие бизнес логикой. В начале мы как правило создаём объект-конетйнер- структуру данных. И очень этому довольны. Потом появляется искушение добавить туда пару методов делающие небольшие изменения и выдающие результат Ведь это так удобно - все данные лежат рядом в полях класса. И дальше пошло поехало. Твой изначально маленький класс для хранения какой-то маленькой сущности превращается в огромных менеджер-контроллер выполняющий ВСЕ что связано с объектом. Это проблема и надо их разделять. Разделять путем рефакторинга.

[@AndriiKuftachov]

Нужно просто меньше читать наркоманские книги. Кстати, много кто считает это жутким антипаттерном достойным прилюдной порки, называется "анемичная модель".

[@0imax]

@@AndriiKuftachov Это дядя Боб-то наркоман?)))

[@andrewduma6467]

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

[@Smolandgor]

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

[@AndriiKuftachov]

100% Просто ООП нафиг не нужен в веб, а его зачем-то пихают везде! Даёшь Go народу!

[@Smolandgor]

@@AndriiKuftachov ООП нужно для любых крупных проектов.

[@avsokolan]

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

[@0imax]

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

[@avsokolan]

@@0imax, ну, во-первых, собрать кучку процедур под одной крышей вместе с данными можно и без ООП. А во-вторых, понятно, что это многое даёт. Но понимание что это дает, и понимание как это работает - разные вещи. Логику работы программы программист обычно понимает, следуя по её листингу, и умозрительно выполняя за процессор команды, т.е. движется по нему также, как впоследствии будет "ползать" процессор, движимый адресным счетчиком. Т.е. то, что вы видите в листинге и затем в экзешнике (поле компиляции), тупо переносится в память и выполняется. Однако же в ООП не так. На класс, который вы видите в листинге, "не ступит нога" адресного счетчика команд. Класс будет в памяти как эталон, а процессор будет перемещаться по многочисленным копиям кода этого класса. И, что важно, копиям, созданным уже в процессе выполнения. В то время, как обычная программа в памяти статична, в ООП мы имеем самомодифицирующийся код, сам себя порождающий. Программа в процессе выполнения с помощью конструкторов и деструкторов "дышит" и видоизменяется в оперативной памяти. Вот в этом и есть разница: обычная программа - код после загрузки в памяти не меняется; ООП - меняется. P.S. да, я знаю, что часто для создания нового объекта не делается полный клон класса, а создаются лишь поля данных. Но это делается для экономии ресурсов, и эта уловка разработчиков компилятора не отражает, как это принято говорить у ООПшнкиов, парадигмы

[@0imax]

@@avsokolan Хорошее описание :)

[@Das.Kleine.Krokodil]

@@avsokolan "собрать кучку процедур под одной крышей вместе с данными можно и без ООП." Например как? В каком языке?

[@rubik6169]

Как по мне, инкапсуляция это не про сокрытие данный, а про то что своим состоянием должен управлять сам обьект. Когда ты setFieldFoo(someDataHere) из класса клиента - ты делегируешь тому классу изменение своего состояния, поэтому set не нарушает инкапсуляции.

[@Acid31337]

Хахаха, не нарушает, ага )))) Смысл инкапсуляции в том, чтоб не завязываться на реализацию внутри. Когда ты своими ручонками ставишь и читаешь значения полей через геттеры-сеттеры, это ничем не лучше чем просто читать значения полей - один хрен код переписывать придется когда логика поменяется.

[@yauhen8883]

@@Acid31337 А что, есть суперуниверсальные подходы, чтобы при любых изменениях логики не приходилось код переписывать? Можно строить архитектуру, чтобы минимизировать эту необходимость и свести к минимуму последствия. И не сами по себе гет/сет решают эту задачу, а удачный подход в анализе и построении модели. Т.е. вопрос не в том применять или нет, а в том как.

[@dmitriyobidin6049]

@@yauhen8883 Геттеры/сеттеры которые мэпят свойства объекта 1 к 1 - плохое решение в любом случае. Объект используется другими объектами только с одной целью - выполнение какого-то логического действия. Как оно выполняется, какие поля при этом используются, как внутри устроен этот объект - не должно быть видимо извне. Всё что должно быть доступно - это интерфейс. А геттеры и сеттеры это ленивый подход, который вроде как похож на инкапсуляцию, но по факту ей не является. Пуская реализация у них будет состоять из возвращения одного поля, но сигнатура метода при этом используемого должна отвечать определенному действию с объектом, а не быть простым геттером.

[@AndriiKuftachov]

Конечно не нарушает! Просто людям нужно рассказывать на выступлениях, а когда ничего умного не могут рассказать, то начинают нести чушь (в данном случае про Егора Бугаенко), хуже, что потом эта чушь расходиться в массы.

[@serhiis_]

вы все хрень несете. геттеры-сеттеры - это свойста (проперти) в любом нормальном языке они есть. И проперти - это часть ООП. А когда у вас есть конструктор и функция - то бишь у вас есть вход данные и выходящие данные -- это функциональный подход а не ОПП подход! Пишите ЧИСТУЮ функцию которая будет принимать данные и возвращать данные! ООП здесь не нужно вообще ни какого!

[@svyatoslavs945]

Хм. Не уверен, что лучше: явное падение программы на неожиданном null (при грамотной обработке ошибок мы просто остановимся и, например, откатим транзакцию) или скрытая ошибка при получении неожиданного пустого объекта, которая позволит дальше работать алгоритму и привести БД в такое состояние, которое потом придется неделю откатывать руками, если это вообще будет возможно. Вопрос очень тонкий, надо смотреть на контекст.

[@Smolandgor]

Может проще поставить проверку на нал и кинуть исключение с каким то вменяемым текстом ошибки? Чем потом в логах видеть нул поинтер ексепшен.

[@svyatoslavs945]

@@Smolandgor Проверку можно поставить там, где мы предполагаем появление null, вопрос в тех ситуациях, когда появление null явно не предусмотрено алгоритмом. Возвращение из функции "пустого" объекта нужного типа может скрыть логическую ошибку и привести к далеко идущим последствиям.

[@dmitriyobidin6049]

@@svyatoslavs945 В этом то и проблема, что все места, где может быть нулл отловить очччень сложно, в некоторых случаях невозможно. Поэтому позиция новых языков изначально направлена на то, чтобы переменные, где возможен нулл были explicit, а всё что явно не указано как возможный null, изначально предполагается как не null.

[@0imax]

Если говорить проще, то смотрите паттерн Null Object. Если он подходит под вашу задачу, то можно сделать пустые объекты. Если не подходит - лучше не надо, а то, как сказали выше, замаетесь искать ошибки. Один вариант, когда всегда пустой объект лучше, чем Null - это контейнеры. Всегда лучше иметь пустой List/Map/Set, чем Null вместо него :)

[@ЕгорМитрофанов-г7ъ]

Спасибо. Всегда с интересом смотрю ваш канал.

[@НиколайТуршиев]

спасибо, неплохо было бы тему проектирования поглубже раскрыть, в целом лойс!

[@kirill4531]

Ещё вставлю свои два цента про null в джаве: Я считаю что любой выдающий метод обязан иметь аннотацию @Nullable или @NonNull Это значительно уменьшит время затраченное на работу с вашим методом в дальнейшем.

[@yauhen8883]

Про какие get/set методы идёт речь. В ооп, про крайней мере в. net-овском представлении этой парадигмы, эти методы как раз наоборот, предназначены для инкапсуляции внутренностей объекта, для защиты его целостности и непротиворечивости, и по-сути представляют его интерфейсные методы. А для доступа к внутренностям, да - есть методы рефлексии, но это к ооп не относится.

[@dmitriyobidin6049]

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

[@0imax]

@@dmitriyobidin6049 Если это поле для объекта некритично - то почему бы и нет. Стандартный пример - лейбл на форме. Каждый раз, когда захотел поменять текст - создавать новый лейбл? Или назвать метод не setTest, а changeText, чтобы формально он не был сеттером?)) Вообще весь UI в любом десктопном приложении юзает и сеттеры, и геттеры в хвост и в гриву, и ничего страшного пока не случилось, окна не сыпятся, кнопки не опадают.

[@iddqdeika632]

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

[@sergeymakarenko1565]

Егор Бугаенко довольно спорная фигура в программировании. Его метод построение приложений крутиться во круг шаблона декоратор и стоит только увидеть программу которые написаны таким образом. Но у него есть реально классные мысли и с некоторыми я согласен. Есть человек Антон Кекс, вот у него тоже немного отличается взгляд на ООП и на java в частности если сравнивать с меинстримами. Но мне его взгляды более симпатичны нежели Егора.

[@IlyaLesnoy]

5:53 - мне кажется в определённых случаях получать null значительно эффективнее, ведь сравнение if(objPtr = some.get()) objPtr->doWork() - адреса на нулл и не нулл эффективнее чем создание временного пустого объекта (или даже пусть пустышки хранятся статически) но дальше же нужно получить доступ к полю объекта или методу чтобы понять что он пустышка. Т.е. с точки зрения машинного кода нулы эффективнее же. Ну а за не обращение к нуллу должен программист следить.

[@0imax]

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

[@Nikita-cm2bm]

Со всем согласен, кроме опционалов. Как раз таки возвращение пустого объекта с дефолтными значениями может привести к неправильному поведению программы и причины такого поведения сложнее выявлять.

[@nailsaggitarius4212]

начинать нужно с языка. ООП на С++ категорически нерекомендуется. Java на этом нужно языке изучать. ООП я понят только когда начал юзать design patterns. Они конечно избыточны бывают, но концепцию уловил только после изучения некоторых этих конструкций. Особенно полезны оказались Strategy, chain of responsibility, commands и state

[@0imax]

Factory method - классная штука, когда нужен нормальный полиморфизм.

[@nailsaggitarius4212]

@@0imax фактори часто используют для инициализации объектов

[@0imax]

@@nailsaggitarius4212 Насколько помню, шаблон factory (он же abstract factory) нужен для создания целой иерархии объектов, это не то же самое, что фактори метод.

[@nailsaggitarius4212]

@@0imax ну естесственно, причем в зависимости от условий создание иерархий может быть разным. Это и есть ООП, концепцию которой упускают на разных курсах. В ООП это как раз ключ, если хочешь владеть ООП

[@0imax]

@@nailsaggitarius4212 Просто мало кто умеет понятно объяснить концепцию ООП. Мне больше всего нравится объяснение на примере компьютерных игр, особенно стратегии: там тебе и инкапсуляция, и наследование, и полиморфизм во всей красе.

[@АндрейБурачковский-й1з]

По поводу null. А разве это не опасно, создавать объекты пустышки, чтоб они обрабатывались наравне с остальными? Это же вносит в программу неявность. Т.е. мне всегда казалось, что лучше особые случаи обработать явно, чем подгонять эти случаи под общую гребенку. Вот условно у нас есть объект, который содержит интовское поле. Есть массив объектов, который заполняется этими объектами и периодически объекты могут быть пустыми. Т.е. в итоге имеем массив, в котором наравне с хорошими данными идут пустые. Есть алгоритм, который считает сумму этих полей во всех объектах в массиве. 2 подхода: 1) Пустые объекты, обозначаются null. И в алгоритме на каждой итерации нужно проверять, что объект не null. 2) Пустые объекты, обозначаются 0 в интовском поле. В алгоритме не надо будет проверять ничего, тупо все суммируем. По мне, второй вариант ведет в бездну из-за его неявности. Пример очень утрированный, но я пытался передать суть обработки пустых и не пустых объектов под одной крышей. Или я не правильно понял вас?

[@kirill4531]

Согласен, пустые объекты это очень специфичная штука, подходящая в конкретных случаях. Общая практика по моему скромному мнению - сразу выдавать null. И это уже работа вызывающего метода принимать решение что с налом делать. Метод выше - знает лучше. Так же обязательно использовать аннотации Налабл и НоНал Кстати не все объекты ты сможешь пустышки сделать и реально потом не понятно как далеко они смогут пробраться, перед тем как их кто-то обнаружит и обработает.

[@rewlads]

наиболее явно возвращать Optional

[@0imax]

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

[@ДмитрийДзюба-о2ъ]

А мне кажется что null и конкретная ошибка лучше, нежели непонятно от куда взятые значения или их отсутствие, вроде ничего не падает, но результат не тот

[@zzz7net]

(Как всегда чётенько == лайк) ;

[@romanbrazhnikov7635]

Разница между теоретиком и практиком в том, что теоретик думает "теория и практика - одно и то же", а практик знает, что это не так. Идеальное ООП в вакууме очень быстро разбивается о реальные проекты, с ограниченными ресурсами

[@S0ERDEVS]

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

[@romanbrazhnikov7635]

@@S0ERDEVS С нетерпением буду ждать от Вас практических примеров, соответствующих тезисам, озвученным в видео.

[@S0ERDEVS]

Я консультирую только в платных подписках и проекте Devs, так что, что в бесплатном доступе такой практики не будет.

[@khatuntsovmikhail6223]

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

[@khatuntsovmikhail6223]

@@S0ERDEVS от вас не требуют индивидуальных консультаций. вам какбы намекают на то, что свои утверждения надо подкреплять примерами (доказательствами) и я (а может не только я) с этим согласен. как ваш подписчик могу уверенно сказать ваши практические видео итереснее, чем видосы с рассуждением о сферическом коне в вакууме. хотя, да, вы художник; вы так видите. з.ы. воля ваша и хозяин - барин. сводить разговор к платным консультациям выглядит кхм... своеобразно. возникает вопрос о том какова цель вашего канала.

[@dmytrobendovskyi7347]

Еще больше запутался после видео, но компрендэ пентэхо

[@alexandersk.8963]

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

[@maksimsergeevich5939]

Недавно для себя понял, что некоторые программы [в основном мета программы] вообще [лучше] нужно начинать писать с того как будет выглядеть конфиг(и) этой программы, или конечные интерфейсы/контракты которыми должен будет пользоваться программист - то-есть с описания того, как ты хочешь, как разработчик взаимодействовать со структурой и кодом этой программы. Например такими программами могут быть сервер приложений или фронтенд фреймворк. Потому что если писать начиная с того чтобы оно просто работало, и походу реализуя желаемый функционал, но еще плохо представляя как будут выглядеть конфиг/контракты, то переписывать все придется раз сто... А иначе ее интерфейсы и конфиги будут максимально убоги и сложны: разбросаны по папкам на разных уровнях вложенности, придется в нескольких конфиг файлах что-то добавлять, копировать и тд.

[@vitaliykrokhalev602]

Шикарные советы! Насчёт пустых объектов, для борьбы с NULL, как я понял, имелись ввиду такие вещи, как Nullable-типы в C#, тип Optional в Java и C++, монада Option/Some/None в Scala и т.д.? Мне они очень помогают, как и монада Maybe.

[@andrewD508]

Скорее больше про паттерн "null object"

[@sergeylastin5276]

3 года у меня ушло, чтобы самостоятельно открыть для себя это, что было настоящим откровением для меня

[@MrSirus83]

А я то думаю, что нам в институте на ООП С++ постоянно впаривали get и set

[@serhiis_]

это из джавы пошло. Они завидовали шарпистам у которых есть проперти.

[@0imax]

@@serhiis_ До сих пор завидуют :) Майкрософт всё-таки не дураки, Checked Exceptions к себе не перетянули (прощайте try-catch везде и всюду, где есть throws), сделали property. Красавчики. Всё-таки есть за что похвалить.

[@2a.kargin58]

Большое спасибо

[@tilekabdilazim8524]

Благодарю. Ценная информация.

[@dimageorgiev5798]

Спасибо лайкнул :)

[@ИгорьДемидов-г2ю]

Благодарю

[@DjLeonSKennedy]

отличный материал BR

[@oknevoksom]

дуже дякую!

[@watchbotzz]

Отличный препод!

[@p588e]

Красавчег! Можно было просто сказать - UML учите и уясните. Ты лукавый архитектор однако - просто скажи, что в основе всего лежит дескрипция на UML, а все остальное техника реализации на конкретном инструменте. Если ТЗ решено на UML, то кодировать можно хоть на турбо бейсике (пусть земля ему будет пухом).

[@0imax]

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

[@BASic_37]

Спрятать ошибку с null, чтоб ее никто никогда не увидел, нарушил логику работы программы и затратить на поиск ошибки кучу времени? Отличный совет!

[@S0ERDEVS]

Вообще не поняли о чем я говорил.

[@BASic_37]

@@S0ERDEVS ну уж как рассказали... Я так понимаю речь шла про паттерн null-object, тогда, как мне кажется надо это уточнять, поэтому что шаблоны не есть какие то принципы парадигмы, а помогают решить всего лишь конкретную проблему. И чтобы использовать данный подход надо четко понимать что ты делаешь и зачем.

[@nailsaggitarius4212]

Объяснение типа вот есть car это объект, вот есть wheel это объект. Педагогически неверный подход. Вернее как концепция катит, но как практическое руководство овладения ООП - неверный вектор. В жизни все не так будет. А вот объяснение на примере адаптера или бриджа паттернов - даст понятие, что можно отделить логику от реализации и зачем. Скажем для mysql и postgresql. Интерфейс один, но подключения разные. Кстати использую Strategy для работы с базами.

[@0imax]

Боюсь, для новичка, не знающего ООП и не имеющего минимального опыта в нём, объяснение адаптера и _особенно_ бриджа будет и вовсе непонятным. Для базового понимания, что такое ООП и зачем оно нужно, вполне подходят житейские примеры. Дальше, с опытом человек поймёт, что это была лишь одна грань, взгляд с одной стороны, и что на самом деле возможности гораздо шире, но понять их без опыта не получится.

[@nailsaggitarius4212]

@@0imax Вообще как я ощутил ООП, то оно сводится к небольшим правилам. 1) Есть некоторая сущность, пусть это будет конкретный класс, который хочет что то получить(данные, обработанные или иные) И есть некий провайдер, он как правило абстрактный, который предоставляет такую услугу, это как правило интерфейс, и есть конкретные реализации этого интерфейса, которые реализуют практическую задачу. Это реализация может быть разной в зависимости от класса, которые практически осуществляет работу. В этой связке важно поддерживать так называеый weak coupling, т.е.слабую связь. Думаю это ключевое в ОПП. Т.е. полиморфизмом его зовут. Заметье в жизни все тоже, проще реализовать что-то если есть некий посредник. Например, есть у вас кредитная карта, но вы не хотите ее светить в сети и других местах. Для того чтобы вас защитить создается виртуальная карта, которая привязана к вашей реальной карте, но которая имеет другой номер и вообще может быть заменена в случае ее компрометации при этом основная карта остается защищенной. Или скажем вы идите в поликлинику, но не хотите использовать свое реально имя, поэтому создается псевдоним но связанный с хэшем вашего реального имени. И даже если хакер взломает базу данные больницы или поликлиники он получит только псевдоним и хэш, которые не приводит его к реальному имени, так как в генерации хеша участвует не только имя и фамилия пациента, но также его электронная подпись. Взломать можно, но это будет в разы намного затреднительней если бы имя и фамилия были просто привязаны к псевдониму.

[@0imax]

​@@nailsaggitarius4212 Как-то сильно сложно звучит)) Мне вот эти лекции понравились больше всего: kzbin.info/www/bejne/b3jHpYqfpNupf7M Отлично легло на знания процедурного программирования и небольшой опыт ковыряния всяких там Delphi. Но да, главный принцип "Рассматривать всё как интерфейс и вызывать всё через интерфейс" - это основа гибкости ООП.

[@nailsaggitarius4212]

@@0imax Да, когда думаешь интерфейсами все лишнее как-то само отпадает. Остается самое главное, только то что нужно сделать. Ведь цель ООП это сделать так чтобы: а) Код можно было легко поддерживать. б) Чтобы любой мог его менять или добавлять что -то. с) был стандартным, чтобы любой программер только пришедший в фирму сразу понимал как устроено приложение, если ему рассказать на каких шаблонах оно построенно. Экономит деньги, время и нервы программиста.

[@0imax]

@@nailsaggitarius4212 Щас придут фанаты ФП и скажут что наше ооп - говно, потому что у них в коде полный бардак и ужас, а в ФП чистые функции и 0 зависимостей)))

[@артёмтема-с3ъ]

Добрый день, Software Engineer - Soer! В видео вы говорите след: ООП подход начинается с проектирования, разделение сущностей на области ответственности, делегирования им полномочий, сокрытие инфы и #### предоставление интерфейса, кот нужен для выполнения поставленной задачи перед объектами###, и не использовать значения кот явл null. Ув. Software Engineer - Soer. Покажите, пожалуйста, код с реализацей "предоставление интерфейса, кот нужен для выполнения поставленной задачи перед объектами" с примером. Пытаюсь разобраться в ООП, но пока не очень получается. Заранее спасибо. Подписался на канал.

[@princessmary5556]

О каком таком сокрытии инфы вы вещаете?

[@xbsxbs22]

Так и не понял, зачем в тестировании залезать внутрь объекта? Мы тестируем обозримое поведение, нам не интересны детали реализации. А экспоузить методы, раскрывающие эти детали реализации, не то чтобы не нужно, но даже вредно. Так тесты становятся зависимыми от реализации этого чёрного ящика, и следовательно, они становятся более хрупкими к рефаторингу. Чего быть не должно. Мы ведь пишем тесты в том числе, чтобы потом провести этот рефакторинг SUT как можно проще.

[@princessmary5556]

Так и есть) Не нужно залазить вовнутрь объекта)

[@tohoto2183]

Уважаемый SOER,а что вы скажите про интерфейсы классов?

[@stazyxtnom4514]

Просто используем котлин и никакой налэксепшн тебе

[@rodionantonichev2412]

нужны примеры, без них - это вода.

[@qwertymangames1800]

Неплохо, но функциональное программирование лучше

[@alienspro]

Не спорю, но у нас во фронтенде сейчас в основном смесь из ООП + ФП, особенно это чувствуется на беке в Node.js. Я как перебезчик из PHP на JS, после ФП стиля испытываю наслаждение разработкой.

[@cover24158]

что такое "лучше?" =)

[@phat80]

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

[@БекнурханНугманов-р5э]

Конечно круто всё объяснил, но новичку будет не понятно !!!

[@aammssaamm]

Новичку сначала надо получить профильное образование.

[@cultofsogga5863]

@@aammssaamm хуйня ваше СНГ образование

[@khatuntsovmikhail6223]

@@cultofsogga5863 хуйня это твоё второё имя. Если ты туп, тебя родили и уронили или выучился в хервой школе а твоим родителям было на тебя срать это твои проблемы. Наше образование оно учит мыслить, балонка же тупо выпускает специалистов с бумажкой ценность которой признают в эуропах и северной америке. На примере своей жены могу сказать. Главная проблема в РФ (не был в других странах и не буду за них говорить) в катострафической недофинансрованности как результат в проффессию не идут молодые и инициативные, а старая совецкая гвадия уходит. Именно многопрофильность мне помогла и помогает в жизни.

[@AndriiKuftachov]

Смысл в том, что ООП придумана совсем для другого. Класс - это способ связать данные и методы в контексте того, как в классических примерах животные ходят, а собака тоже ходят, но как-то особенно. Но документ не может себя распечатать или переслать, а платеж сам себя оплатить. Это абсурд. Сейчас класс - это просто группировка методов по какому-то признаку, чтобы их было удобнее дергать. Поэтому подход из Go и является самым адекватным для большинства современных задач, для всего остального есть Си... Ну и JS на фронте, куда же без него.

[@Das.Kleine.Krokodil]

а что мешает на жаве то же самое делать? вообще паттерны дают установку что композиция лучше наследования

[@Das.Kleine.Krokodil]

" платеж сам себя оплатить. Это абсурд" почему абсурд?

[@TheHardPotter]

Как я мог это пропустить

[@majestif]

Здравствуйте, а перегрузка методов по количеству/типу параметров это полиморфизм? Если да то какой?

[@Mr43046721]

Перегрузка никак не связана с полиморфизмом)) это просто тот же самый метод, только с другим набором данных

[@S0ERDEVS]

Denis, вообще-то перегрузка считается ad-hoc полиморфизмом.

[@МаксимМалышев-р5е]

@@Mr43046721 , вообще-то перегрузка функций это статический полиморфизм (в С++ например). Вы просто не понимаете, что такое полиморфизм. Если сказать грубо, полиморфизм - это способность функции с одним и тем же именем обрабатывать данные разных типов. По вашему, если это свойство становится возможным только во время компиляции, то оно нивелирует полиморфизм по определению ? Это неправильная логика

[@HelloWorld-fy8cd]

Это вроде называется статическим полиморфизмом

[@0imax]

В разных языках называется по-разному. В C++ такая перегрузка называется статическим полиморфизмом, чем (на мой взгляд) нарушает сам принцип "Полиморфизм" - разное поведение объектов при одинаковом обращении с ними. Если перегруженные методы называются одинаково, то и делать они должны примерно одно и то же. Полиморфизм же позволяет сделать _одинаковый_ вызов у объектов, имеющих _разное_ поведение. Если у нас меняется и тип, и количество параметров, при этом функция выполняет сходные действия, это на полиморфизм совсем не похоже. Например, в Java перегрузка - и есть перегрузка )) Неспроста.

[@sergeigrv441]

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

[@0imax]

Не то чтобы "нужно", скорее - "удобнее". Но задумывалась эта парадигма для другого, а именно - объединить данные и методы работы с ними, а заодно ограничить область ответственности конкретного кода. Так-то программы на СИ вполне себе делились на программистов)

[@serhiis_]

разбить программу на 100 программистов можно легко без ООП! Наоборот с использованием ООП эту задачу сделать намного сложнее! Чем более связанные модули вашего огромного на миллион строк проекта - тем сложнее его разобрать, тем больше проблем вызывает изменение одного файлы. Наоборот чем более автономные файлы - тем проще их тестировать, тем меньше проблем вызывает масштабирование и модификация файла. Наследование и полиморфизм приводит к геометрическому увеличению сложности проекта. Зайдите на любой опенсоурс репозиторий в котором авторы задрачивались в ООП у увидите что пока вы не разберете по полчкам все 10 тыс классов вы вообще ни чего не поймете как тут работает 25 тыс наследований и абстракций! Такие проекты к сожалению есть и я не преувеличиваю и авторы явно убеждены что у них подход когда один файл завязан на 10тыс других файлов - это хорошо.

[@0imax]

@@serhiis_ Только вот причина бардака в проекте - отсутствие какой-либо продуманной архитектуры, а вовсе не использование ООП. С таким же успехом можно написать в чисто процедурном стиле, бездумно раскидав код по кучке файлов, которые надо подключать чуть ли не все ко всем.

[@serhiis_]

@@0imax не процедурном а функциональном. Но в целом согласен если бы не человек - то и загрязнения планеты бы небыло. Только вот проблемы с архитектурой встречаются зачастую в проектах на плюсах с "глубоким" ООП. Проекты где ООП применяется лишь там где оно нужно очень мало.По крайней мере на опенсорсе. Хотя опенсорс считает по чистоте кода намного чище продакшена

[@0imax]

@@serhiis_ именно в процедурном, как это было во всяких си и паскалях. Функциональщина же в корне отличается от процедурного стиля тем, что является декларативным, а не императивным. И отсюда сложность в чтении кода: нормально написанный в императивном языке код читается как простой английский текст. А учитывая, что бОльшую часть времени программист код ЧИТАЕТ, а не пишет, простой и понятный код - это огромный плюс.

[@yarobest9594]

огонь

[@HayocSparapet]

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

[@dann1kid]

Для самостоятельного поведения обьекта, чтобы ему не нужно было все время указывать, что нужно делать. Это прообраз автоматонов на фарбрике, только в мире программирования.

[@vas_._sfer6157]

@@dann1kid В структурном это также реализуется.

[@phat80]

@Beginer Programming пиши на C, кто мешает? Да и во многих других языках никто не заставляет использовать ООП, по крайней мере в своем коде. Объекты-то все равно придется создавать, так как использование многих библиотек завязано именно на объектах. В остальном можешь писать в простом процедурном стиле. Но посмотрим, как ты будешь справляться, когда приложение разрастется. Для маленьких программ ООП и не обязательно, а может даже и вредно, а вот в больших... очень тяжко придется без ООП.

[@phat80]

@Beginer Programming зачем ты мне что-то доказываешь? ))) Меня устраивает ООП, мне удобнее жить в мире ООП. Тебе удобнее без него, ради бога ) И оно не модное. Оно было модным в 90е-2000е. Сейчас уже модно ООП наоборот грязью поливать и создавать языки без ООП или его частичной реализацией. Можно в пример привести Go и Rust. Только вот, если Go как-то выстрелил, то Rust пока буксует. Не торопятся люди отказываться от ООП.

[@phat80]

@Beginer Programming а что такое твое «на кой нужно это ООП»? Это был вопрос что ли? Мне показалось, что утверждение. Да и когда пишешь что-то в публичном пространстве, ты фактически начинаешь диалог с любым человеком, который может прочитать твое сообщение. Если не хочешь диалогов или хочешь диалогов только с конкретными людьми, не стоит их вести в общем доступе. А то какие-то совсем смешные претензии получаются )))

[@gaspromchik728]

как я понимаю ответственость атомачиески опредиляет значимость обектов и атоматически выстраивает их последовательность, и структуру или я что-то напутал ?

[@lavcoder]

Скачал книгу Крэга Лармана, которую Вы упоминаете в видео. Ввел сразу же в поиске слово "декоратор" и что я вижу? Не нашел вообще главы о декораторе! Не судите строго, может я тупой или чего-то не понимаю, но... если в книге нет отдельной главы про декоратор, то... я не понимаю тогда, можно ли ее использовать как некий учебник по паттернам?..

[@S0ERDEVS]

Ты его спутал с "Бандой четырех", Ларман автор "GRASP". Это немного разные работы.

[@firstnamelastname3464]

Ничего не понял, но видно что вы очень сильно стараетесь! Легче воспринимать ваши видео по сравнению с другими.

[@СусловРостислав]

1:40 бос!

[@user-hr4lp8ro2h]

Найс спасибо

[@neoppanda]

Замыливание фона для текста видеть неприятно

[@boycovclub]

ООП самое лучшее

[@boycovclub]

@@bashshell114 но проверять вы конечно не будете)

[@lavcoder]

Порекомендуйте книги по ООП! Спасибо.

[@albrehtdurer557]

капитан очивидность?

[@ДиШи-о7д]

А зачем? автор делает ограничения для просмотра по регионам ?

[@a.o.yaroslavov]

Главное что нужно знать, ООП это: не классы, не virtual, не наследование, не private/protected/public, и даже не инкапсуляция... вся эта мишура - это особенности реализации инструментов ООП для конкретного языка, например С++.

[@princessmary5556]

Да неужели? Если ооп - это не классы с наследованием и полиморфизмом, тогда что же такое ооп?

[@ПуляевГригорий]

Про Null очень правильное замечание, но это к ООП никакого отношения не имеет. Чем плохи get и set так и не ясно.

[@0imax]

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

[@ПуляевГригорий]

@@0imax Это понятно, но я посмотрел выступление Егор Бугаенко и он утверждает что их вообще не должно быть...

[@0imax]

@@ПуляевГригорий Не смотрел ещё, но по-моему, это бред. Или он хочет сказать, что всё надо передать в конструкторе? Ну вот у меня форма, на ней лейбл. Мне надо поменять надпись. Делать новый лейбл?) Либо человек заболел ФП и пытается впихнуть его прелести в ООП. Заинтересовало. Послушаю, может он что-то другое имел в виду :)

[@АмэйзингЧенал]

@@0imax та он сам ниче непонял , он тупо согласен с кем-то а сам и неразобрался как это провернуть . Гавно ролик и он гавно

[@Ivan-uo6xy]

Software Engineer - Soer Сергей (надеюсь, я верно понял и это ваше имя), если бы вы начинали изучать программирование с 0 в 2019, какой бы вы язык выбрали для начала?

[@AndriiKuftachov]

По приоритету: 1. Если есть знакомый, который может помочь хотя бы с бесплатной стажировкой, то язык, который скажет он. 2. Если нет знакомого, то смотрим джунские вакансии по региону. 3. Если нет джунских вакансий, смотрим вообще что есть, учим то, чего больше, потом идём и просимься на стажировку. 3.1. При других равных, в PHP есть фреймворки с более низким порогом входа, как Yii2, который почти умер и Laravel, который ещё живой. 3.2. Или фронт можно учить, js + какой-то фреймворк, так можно попробовать и удалённую работу на крайний случай найти, и порог тоже меньше, чем в Java или C#. Потом язык поменять вообще не проблема, когда уже опыт есть.

[@экспертэксперт-з3я]

Тупейший вопрос. Почему идиоты всегда его задают. Причем тут год? Открой список самых востребованных языков и ты увидишь, что там ничего не меняется с годами - это С, С++, Java, Assembler. Начинать лучше в сего с С. Это даст общее понимание программирования, общее понимание как работает память, как работает компьютер. По С есть хорошие подробные книги с детальным разбором примеров. Не встречал такого в книгах по другим языкам.

[@Das.Kleine.Krokodil]

@@экспертэксперт-з3я *"Начинать лучше в сего с С"* и этот человек говорит про тупые вопросы

[@экспертэксперт-з3я]

@@Das.Kleine.Krokodil ты хочешь с этим поспорить?

[@Das.Kleine.Krokodil]

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

[@артёмтема-с3ъ]

Вечер у камина)аххаха

[@pekhov21]

Как насчет подробнее про ооп)

[@S0ERDEVS]

Никак

[@pekhov21]

@@S0ERDEVS 😝

[@HardSonowDosker]

Some kind of trolling?

[@smertvichdreng]

как и все про ооп просто какая-то жвачка.

[@СергейПресняков-о4р]

Как человек, который ничего не знает про ООП, я не понял ничего.

[@aleksandrsavvopulo4510]

Эти рассуждения про null.. Он НУЖЕН, и объекты "пустышки" это большее зло чем null. Объясняю. Если у вас в приложении появляется исключение это значительно лучше, чем если приложение не отрабатывает как надо, и при этом не выдает ошибок. Это сродни пустому try..catch. Вроде не падает, но и не работает правильно. Для регистрации исключений есть масса инструментов, и это дает возможность реагировать быстро. Далее. NULL не объект, да. Это отсутствие объекта. ООП не позволяет существовать ситуации когда наличие ссылки на другой объект опционально? Заменив NULL на пустышку вы неизбежно добавите в класс поля типа isExists или подобные костыли, потому что вам НУЖНО знать реальный это объект или нет. Чтоб не страдать с NULL возьмите себе за правило возвращать Optional в ситуациях когда позволяется иметь ссылку на объект опциональной, тем самым явно давая понять, что объекта может тут и не быть. И наоборот, в тех случаях, когда объект быть обязан - не нужно Optional. Возвращаться должен сам объект и проверок на null там не нужно. В этом случае, если что то идет не так - вы сразу об этом узнаете. До того, как закончится 3х часовая джоба генерации всевозможных отчетов с неправильными результатами. Бугаенко не находит отклика среди большей части разработчиков. И на это есть очевидные причины.

[@wylysypydystyshky]

Кто не программировал, тот ничего не понял)

[@0imax]

Да и тот, кто программировал, понял не всё и не сразу)

[@Al.Sy.]

На Lisp? )

[@0imax]

@@Al.Sy. asm)

[@Al.Sy.]

@@0imax слишком атомарно. ) Но в некоторых случаях неизбежно.

[@0imax]

@@Al.Sy. Реально, не зная ооп, понять, о чём он говорит, крайне затруднительно))

[@maksimsergeevich5939]

И многие не понимают, что фишка ООП это тупо абстракция через объекты и наследование свойств этих объектов. В остальном, принципы и правила из ООП давно успешно применяются и в других парадигмах программирования. И если убрать это общее из ООП, то останутся просто объекты и наследования, то есть ничего важного. Просто я пишу на ноде и js и я зае$ался слушать глупости сишарперов о том, что js говн0 так как там нету ООП. Мне в свою очередь дико и больно смотреть на код ООП-шников, которые как в секте вынуждены и обязаны все писать через классы и наследование. В ООП языках простейшие вещи требуется реализовывать с помощью каких-то нативных костылей - простое сделано сложным. ООП это тупо секта которая делает простое сложным, чтобы своим адептам внушать, что они самые умные и грамотные. То-есть по их мнению, полиморфизма, повторного использования кода, сокрытия сложности и инкапсуляции не добиться вообще никак без того, чтобы все писать через классы и наследования. А появляются у них эти мысли потому, что они тупо выполняют правила которые не понимают. У меня друг пишет на шарпах под Юнити, но он мне нихеpа не может объяснить зачем нужны классы. Просто вот нужны и все, якобы без них код = говнокод, потому что так Сакутин говорит.... xD

[@princessmary5556]

Голословное бла бла бла. Ваше "останутся просто объекта и наследование, то есть ничего важного" звучит как: "останется просто код, т.е., ничего важного". Бред одним словом.

[@DjLeonSKennedy]

По возможности ООП вообще лучше не использовать

[@0imax]

По возможности программу вообще лучше не писать.

[@serhiis_]

@@0imax функциональный подход более гибок и легче тестировать чем ООП. Не несите чушь! По возможности нужно писать чистые функции. Чем допускать миллионы промежуточных состояний обьекта, которые даже в теории не возможно все протестировать. А еще обычно бывает кучу глобальных обьектов - костыль называется синглтон, официальный ООП костыль глобальных переменных!

[@0imax]

@@serhiis_ где вы видите чушь? Да, по возможности надо избегать промежуточного состояния, тогда тестирование будет как два пальца. Но реальный мир показывает, что без состояния в большинстве случаев не обойтись. Ну а вами нелюбимый синглтон - это всего-лишь один из паттернов, бездумное применение любого паттерна портит код в той или иной степени.

[@serhiis_]

@@0imax глобальные обьекты нужны только в ОС и движке игры. Я же вижу что в языках и либах sharedInstance встречается чуть ли не в каждом классе! Причем не только либах индусов, но и Apple и google! Пример юзания либы начинается с волшебного вызова sharedInstance либы. Наверно авторы либы реализовали внутри либы ОС и еще движок игры запихнули в придачу. Потому что обьяснить иначе 100мб либу на 100 функций от гугла я ни как не могу!

[@0imax]

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

[@legoo-lego1305]

Лайк, но ни хрена не понял.

[@amatcia1]

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

[@saharaprotocol]

6ля, у тебя монитор горит.

[@zelmanfeig5404]

К практике ты так и не перешёл, пудришь людям мозги бумажно-книжной белибердой.

[@kakbudtobi]

Проблему с null решает паттерн "особый случай".

[@unformedvoid2223]

Если убрать всю эту мудрёную философию, которую уже впоследствии навешали на ООП, то ООП - это тупо надстройка над процедурным программированием. Си с классами короче. Всё равно ведь процедуры пишут все, несмотря на то, что называют методами. Какая разница, если тело метода состоит не из объектов, а из тех же инструкций…

[@princessmary5556]

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

[@unformedvoid2223]

@@princessmary5556 ага, а в итоге, получается либо свалка никому не нужного кода, либо опять же меняют существующий код. Менять существующий код - не ущербная практика. Напротив, не менять существующий код - вот что ущербно. Тем более, что добавить ещё один кейс - это по-сути расширить код, а не изменить. Совершенно не важно, что с классами этот код находится в другом файле (да и не обязательно, что в другом). А почему так всё шиворот-навыворот в мейнстриме? Потому что в мейнстриме ущербные языки, которые не помогают программисту с изменениями. Потому, что любое изменение в коде, написанном на таком языке - это туева хуча багов и боль в пятой точке. В общем, после того, как я познал дзен функциональных статически типизированных языков меня весь этот хайповый лепет не трогает. У меня факты на руках, мой личный опыт. Какие там классы, какие лучшие практики, не смешите. ООП - это уже плохая практика. В нашей компании я это могу рассмотреть на примере моей F# команды и остальных C#. Как вы поняли преимущество не на стороне C#. А что касается полиморфизма, то и тут ООП достаточно хиленько. Поддержка полиморфизма у функциональных языков гораздо шире.

[@princessmary5556]

@@unformedvoid2223 Нет никаких "в итоге получается свалка". Не надо выдумывать. Менять существующий код - это всегда ущербная практика. Потому что подобные правки вынуждают выполнить весь цикл разработки: от тестирования до развертывания. А вот голословное заявление, что якобы ущербно не менять существующий код - это просто бред. А заявлять об ущербности менйстримовых языков - это уже клиника. После таких заявлений, я полагаю, что вы - ангажированный идиот.

[@unformedvoid2223]

@@princessmary5556 ой, извините, что задел ваши религиозные воззрения. Вы наверное мастурбируете на какой-нибудь кривой пайтон или вовсе джаваскриптизёр. Я не полагаю, я знаю, что вы идиот. Не менять код - ущербная практика и я видел эти свалки кода, построенные по «лучшим практикам», которые никто не меняет, но в которых куча бесполезных спутанных классов. В тестировании и развёртывании ничего плохого нет, надеюсь слышали о CI/CD. Ещё раз, опыта мне хватает, чтоб такое говорить. Если вас что-то не устраивает - выход знаете где. Вас с вашим мнением под мой комментарий никто не звал.

[@princessmary5556]

@@unformedvoid2223 Я вас не извиняю. Не люблю голословных дебилов-балаболок, которые несут всякий бред. Так например, ни в одном из моих сообщений нет даже намека ни на какую религию. Не пишите мне больше ничего.

[@cruelm4n]

Так, я успел продеградировать на этой неделе на видосах по тик-ток и прочей ереси, а теперь готов развиваться на годном контенте =)

[@АндрейШувалов-ы8е]

Очень интересная тема, и очень больная для меня, т.к. уже долгое время у меня в голове ООП не складывается в какую то единую четкую картину. Мне всегда очень помогало для понимания, рассмотрение реального кода. У вас есть на примете какие то существующие опенсорс проекты, где используется ООП, чтобы можно было "потыкать" код, посмотреть что, как и зачем. Просто с этими учебными примерами, которые часто вижу, конечно все здорово, но довольно слабо представляю как мне в каком то практическом примере, может помочь создание очередного объекта машины или кошки (утрированно)

[@sackeja]

Попробуй паттерны поизучать, сразу станет понятнее

[@maksymgrom1631]

Magento 2 заходи на гитхаб и будет тебе тысячи файлов чистого ООП

[@dimon.digital]

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

[@nikolaysokolov9027]

Спасибо!

[@aleksey6639]

Раскрывать внутренности объекта для тестирования не очень хорошая практика - тесты будут хрупкими, по идее тесты должны опираться на публичный интерфейс

[@0imax]

Должны, но не всегда так получается. Если надо тестировать говнокод, то есть 2 варианта: либо лезть внутрь, либо рефакторить весь этот говнокод. Первый вариант дешевле))

[@1pavka]

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

[@klerg321]

Хмм... кажется наоборот, лучше, если приложение упадет с null поинтер, когда он придет туда, где его не ждали

[@DoctorKrolic]

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

[@0imax]

@@DoctorKrolic паттерн Null Object (как и любой другой паттерн) не нужно пихать всюду и бездумно. Есть случаи, где он нужен, а есть, где вреден. Затыкать NPE с помощью пустого объекта - это антипаттерн, т.е. неправильное архитектурное решение.

[@HelloWorld-fy8cd]

Насчет NULL и пустых объектов. Согласен, что лучше возвращать пустой объект ничего не делающий нежели NULL. Но этот самый NULL в разных языках программирования свой смысл имеет и тип. Например в С++, когда мы динамически создаем массив из n - элементов: MyClass * p = new MyClass [n] , то данная конструкция не сработает, если в MyClass не прописан конструктор по умолчанию. А если мы хотим сделать валидной конструкцию Obj1=Obj2, то просто переопределяем оператор "=" и возвращаем по ссылке "самого себя" рызыменовывая указатель *this. Но это в С++ так, а как в других языках? было бы неплохо привести конкретные примеры. А ролик в целом полезный, правда я не понял почему нужно отказываться от интерфейсов Set и Get ведь, это "официальные" открытые методы которые предоставлены внешним объектам, которые имеют возможность влиять на объект, по правилам определенным программистом. Почему это считается нарушением инкапсуляции, ведь класс официально разрешает доступ к себе, по своим правилам. Конечно в С++ есть friend -функции , вот они более опасные, так как имеют доступ ко всему классу, в том числе и к приватным членам.

[@АндрейБурачковский-й1з]

friend - советуют вообще не использовать, или использовать в самый последний момент, слишком уж он развязывает связность. Про геттеры и сеттеры - лучше чтоб их было как можно меньше (особенно сеттеров). Да и вообще лучше чтоб интерфейс был поменьше.

[@Чёрнаякошка-ц6к]

Лично я в переборе массива объектов в начале всегда проверяю на Null. Это не сложно. Это не долго. Единственный раз, когда я использовал объект-пустышку это при реализации класса звукового драйвера. При запуске программы сканировал все доступные аудио-библиотеки, и если ни одна не была найдена, то в качестве текущего ставился пустой драйвер, дабы избежать вылета программы. Суть пустышек - это допуск ситуации, когда отсутствие результата - тоже результат, в остальных случаях - Null, криво реализованных - Exception.

[@vladimiratanov1926]

А выбросить ошибку?

[@Чёрнаякошка-ц6к]

@@vladimiratanov1926 Выбросить ошибку на то, что в системе нет устройства воспроизведения звука? - это абсурд. Максимум - выбросить сообщение в консоль, что звука не будет. Программа в немом режиме может прекрасно работать.

[@vladimiratanov1926]

@@Чёрнаякошка-ц6к а зачем запускать звуковой драйвер, если в системе нет звукового устройства?

[@AndriiKuftachov]

Ссылаться на Егора - полный зашквар! Он вообще какую-то несуразную чушь несёт, надеюсь, что просто для хайпа.

[@S0ERDEVS]

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

[@AndriiKuftachov]

​@@S0ERDEVS Я написал о том, как сейчас реально используют классы, а не то, как их использовать правильно. Но их так используют просто потому, что ООП не нужен для большинства современных проектов, многие языки навязывают ООП из коробки. Вот любой контроллер, какие действия он выполняет? Это просто сгруппированные функции. В большинстве случаев действует Deus ex machina, а не сам класс, который люди создают. А класс - это абстракция, которая описывает что-то, что само по себе является деятелем, иначе нет смысла использовать ООП при проектировании.

[@AndriiKuftachov]

@@S0ERDEVS Ну и странно слышать от Вас про get/set, который нарушает инкапсуляцию. Это же очевидно, что как раз наоборот. Наличие или отсутствие get/set для определенных полей как раз и говорит о API класса. А та чушь от Бугаенко - это путь на темную сторону, людей, которые не знает как работает компьютер и думают, что создать заново класс лучше, чем изменить значение в нем. Хотя иммутабельность может быть полезна, когда работа с памятью дешевле, чем расходы на синхронизацию, но это сильно ограниченный набор задач. P.S. Это следствие перегретого рынка, когда железо сильно дешевое, а программистов сильно не хватает и во многих задачах вообще не думают про эффективность. P.P.S. И только в Go каждая уважающая себе библиотека выложит тесты, чтобы показать, что у нее после старта почти не будет аллокаций.

[@S0ERDEVS]

@@AndriiKuftachov при чем тут создание нового класса? Речь идет о создании нового инстанса класса (объекта). И безусловно это лучше, чем использовать уже созданный объект в новом контексте, с переопределением свойств. Это же сколько сайд эффектов можно словить, если послушаться Ваших вредных советов. Что касается работы компьютера, то поясните более подробно, что Вы имеете в виду. А то спектр вопросов слишком велик.

[@AndriiKuftachov]

@@S0ERDEVS Работа с памятью не бесплатная, а то потом говорят, что Java медленная... Никто не говорит об использовании объекта в новом контексте, но если у конкретного объекта что-то поменялось - это не повод создавать новый. Ну и проблемы с побочными эффектами сильно преувеличены, в отличии от проблем вызванных потерями производительности при функциональном подходе... Это уже конечно не ООП, но Вы сами начали про побочные эффекты.

[@uknow2908]

Спасибо! Насчёт ответственностей новая информация.

[@gekale8658]

пример бы кода без геттеров и сеттеров а то описанию константа какая-то а не объект