Именно что обосновано, попробуйте послушать и поймете что кое в чем он прав.
Но! Есть все-же сферы где классическое ООП (как в C++/Java/C# и т.д.) — именно что упрощает и незаменимо. И сфера эта — построение иерархии контролов/элементов управления/виджетов для GUI. Виджеты имеют, как правило, несколько уровней иерархии. Так же бывает удобно свою реализацию добавить. Все они участвуют в построении дерева.
Не даром на том же Rust нет ни одного толкового GUI-фреймворка, который бы позволял сделать современный UI.
P.S.
Дополню примером из видео:
1. Наследование — суть: как ПЕРЕИСПОЛЬЗОВАТЬ код без его копирования?
— композиция
2. Инкапсуляция — суть: Как ИЗОЛИРОВАТЬ части системы, чтобы изменения одной части не ЛОМали другие?
— модули в Rust
3. Полиморфизм — суть: Как ПИСАТЬ код, который работает с разными типами данных
S>Именно что обосновано, попробуйте послушать и поймете что кое в чем он прав. S>Но! Есть все-же сферы где классическое ООП (как в C++/Java/C# и т.д.) — именно что упрощает и незаменимо. И сфера эта — построение иерархии контролов/элементов управления/виджетов для GUI. Виджеты имеют, как правило, несколько уровней иерархии. Так же бывает удобно свою реализацию добавить. Все они участвуют в построении дерева. S>Не даром на том же Rust нет ни одного толкового GUI-фреймворка, который бы позволял сделать современный UI.
Что опять? На позапрошлой работе я когда сдавал дела, мы проходились по всему моему написанному коду и я объяснял что и как там. Запнулся я только в двух местах. Все легко восстанавливалось в памяти благодаря ООП. Изменения в процессе работы тоже легко давались. ООП я считаю своей сильной стороной и многие вещи без него я не то что бы не написал бы, а делал бы их на много дольше. Вообще люди делятся на две категории: одни поняли основной закон разработки, другие — нет. ООП это про первых. Про UI. Вообще это обычно самая простая часть системы, которая ни делает ни чего, кроме того что отображает данные, там не только можно обойтись без ооп(хоть это и не очень привычно), но и не обращать внимание на некоторые недостатки кода.
S>Но! Есть все-же сферы где классическое ООП (как в C++/Java/C# и т.д.) — именно что упрощает и незаменимо. И сфера эта — построение иерархии контролов/элементов управления/виджетов для GUI. Виджеты имеют, как правило, несколько уровней иерархии. Так же бывает удобно свою реализацию добавить. Все они участвуют в построении дерева.
когда-то в ооп было три принципа.
потом появился четвёртый, а один из предыдущих стал антипатерном
и еще много чего произошло за последние 20 лет.
ооп сам по себе хорош. просто мало кто умеет его правильно готовить.
лично я считаю, что для эффективного кодинга, нужно обладать знаниями в ооп и функциональщине.
только тогда у тебя расширяется кругозор
и два этих принципа отлично дополняют друг друга
Здравствуйте, Свободу Анжеле Девис и Юрию Деточкину, Вы писали:
САД>когда-то в ооп было три принципа.
Когда то было 7 принципов:
Основными принципами являются: абстрагирование, ограничение доступа, модульность, иерархичность, типизация, параллелизм и устойчивость.
Я в свое время так на собеседованиях троллил, ибо от меня ожидалось что я 3 назову и других . Но 23 летние сеньеры чаще всего не могли оценить нестандартные ответы, правда мне пофиг было, я для тренировки на собеседования ходил. Сейчас увы, гуглить пришлось.
Здравствуйте, Shmj, Вы писали:
_>>И где обоснования?
S>Он пытается оправдать Rust, по сути. Т.е. доказать что отсутствие полноценного ООП в Rust это не недоработка — а будущее и отсекание дерьма.
Здравствуйте, Shmj, Вы писали:
S>Этот чувак уже третье видео обоснованно унижает ООП:
Завидую тебе, можешь слушать толстенные видео, где рандомный чувак гонит пургу и воду вперемешку.
У меня давно на таких нет времени и терпения.
S>Именно что обосновано, попробуйте послушать и поймете что кое в чем он прав.
S>Но! Есть все-же сферы где классическое ООП (как в C++/Java/C# и т.д.) — именно что упрощает и незаменимо. И сфера эта — построение иерархии контролов/элементов управления/виджетов для GUI. Виджеты имеют, как правило, несколько уровней иерархии. Так же бывает удобно свою реализацию добавить. Все они участвуют в построении дерева.
S>Не даром на том же Rust нет ни одного толкового GUI-фреймворка, который бы позволял сделать современный UI.
Да, похоже.
Что дальше? Будем искать здравое зерно в мегабайтах потока сознания ИИ?
Здравствуйте, Qulac, Вы писали:
Q>Что опять? На позапрошлой работе я когда сдавал дела, мы проходились по всему моему написанному коду и я объяснял что и как там. Запнулся я только в двух местах. Все легко восстанавливалось в памяти благодаря ООП. Изменения в процессе работы тоже легко давались. ООП я считаю своей сильной стороной и многие вещи без него я не то что бы не написал бы, а делал бы их на много дольше. Вообще люди делятся на две категории: одни поняли основной закон разработки, другие — нет. ООП это про первых. Про UI. Вообще это обычно самая простая часть системы, которая ни делает ни чего, кроме того что отображает данные, там не только можно обойтись без ооп(хоть это и не очень привычно), но и не обращать внимание на некоторые недостатки кода.
Вот ты пишешь "Мои", "Я", "Своё", "Мой". Но ведь мир далеко не идеален, и написанный код далеко не всегда твой.
Мне, например приходится работать с огромной иерархией, где долго нужно напрягаться, чтобы осознать кто от кого наследуется, и какая именно виртуальная функция вызовется. А если я вызываю базу, никто мне не расскажет, дойдёт ли это до самого верха, если я вручную не пройдусь по всей иерархии. Конечно, это кривой дизайн. Но он УЖЕ есть, и с ним надо жить. Вот тут ООП откровенно мешает.
Здравствуйте, Doom100500, Вы писали:
D>Здравствуйте, Qulac, Вы писали:
Q>>Что опять? На позапрошлой работе я когда сдавал дела, мы проходились по всему моему написанному коду и я объяснял что и как там. Запнулся я только в двух местах. Все легко восстанавливалось в памяти благодаря ООП. Изменения в процессе работы тоже легко давались. ООП я считаю своей сильной стороной и многие вещи без него я не то что бы не написал бы, а делал бы их на много дольше. Вообще люди делятся на две категории: одни поняли основной закон разработки, другие — нет. ООП это про первых. Про UI. Вообще это обычно самая простая часть системы, которая ни делает ни чего, кроме того что отображает данные, там не только можно обойтись без ооп(хоть это и не очень привычно), но и не обращать внимание на некоторые недостатки кода.
D>Вот ты пишешь "Мои", "Я", "Своё", "Мой". Но ведь мир далеко не идеален, и написанный код далеко не всегда твой.
D>Мне, например приходится работать с огромной иерархией, где долго нужно напрягаться, чтобы осознать кто от кого наследуется, и какая именно виртуальная функция вызовется. А если я вызываю базу, никто мне не расскажет, дойдёт ли это до самого верха, если я вручную не пройдусь по всей иерархии. Конечно, это кривой дизайн. Но он УЖЕ есть, и с ним надо жить. Вот тут ООП откровенно мешает.
D>ЗЫ. Видос не смотрел.
Зачем напрягаться. Если можно вывести на диаграмму(в студии можно) выведи, что бы все перед глазами было. Я даже если в незнакомой бд нужно разобраться вывожу нужные таблицы на er-диаграмму и уже ее смотрю, это на много легче чем прыгать по зависимостям.
Q>Зачем напрягаться. Если можно вывести на диаграмму(в студии можно) выведи, что бы все перед глазами было. Я даже если в незнакомой бд нужно разобраться вывожу нужные таблицы на er-диаграмму и уже ее смотрю, это на много легче чем прыгать по зависимостям.
Вот нифига не напряжно, когда в очередной версии вылетает какой-то баг, и ты начинаешь генеририваь диаграммы и втыкать заново. Потому что это всё меняется и живёт, а прошлый раз ты здесь был несколько месяцев назад.
Здравствуйте, Doom100500, Вы писали:
D>Здравствуйте, Qulac, Вы писали:
Q>>Зачем напрягаться. Если можно вывести на диаграмму(в студии можно) выведи, что бы все перед глазами было. Я даже если в незнакомой бд нужно разобраться вывожу нужные таблицы на er-диаграмму и уже ее смотрю, это на много легче чем прыгать по зависимостям.
D>Вот нифига не напряжно, когда в очередной версии вылетает какой-то баг, и ты начинаешь генеририваь диаграммы и втыкать заново. Потому что это всё меняется и живёт, а прошлый раз ты здесь был несколько месяцев назад.
Ну так это при любом подходе так. Серебряной пули нет.
Здравствуйте, Marty, Вы писали:
M>Так где обоснования?
Но вообще там же 3 видео обоснований, у вас же есть яндекс-браузер — он вроде умеет конспектировать видое.
А суть вот в чем. Чел. приводит примеры, когда ООП решает некую проблему. Как-то переиспользование и расширение кода. И показывает как ту же самую проблему можно решить без ООП современными средствами более удобно.
Или то же расширение, которое ООП решает механизмом наследования — показывает что это не удобно и что лучше не наследование (которого в Rust нет вовсе) — а агрегация.
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, Doom100500, Вы писали:
D>>Здравствуйте, Qulac, Вы писали:
Q>>>Зачем напрягаться. Если можно вывести на диаграмму(в студии можно) выведи, что бы все перед глазами было. Я даже если в незнакомой бд нужно разобраться вывожу нужные таблицы на er-диаграмму и уже ее смотрю, это на много легче чем прыгать по зависимостям.
D>>Вот нифига не напряжно, когда в очередной версии вылетает какой-то баг, и ты начинаешь генеририваь диаграммы и втыкать заново. Потому что это всё меняется и живёт, а прошлый раз ты здесь был несколько месяцев назад.
Q>Ну так это при любом подходе так. Серебряной пули нет.
ВОООТ. Так что я и говорю. В этом случае ООП вообще не помогает, а скорее мешает. Вместо того, чтобы функционал был сосредоточен в одном месте — он рзмазан по всей иерархии. Это просто пример. Этот код был написан когда ООП возводили в абсолют, а потом он разросся. В том случае напрашивается рефакторинг, например, на композицию из функциональных элементов но никто этим заниматься не будет, так как на решение ДЕВЕЛОПЕРСКИХ проблем в будущем бюджета, естественно, нет — бизнесу нужны деньги сейчас.
Думаю, что если иерархия растёт в глубину (новый функционал наследует предыдущий с добавлением плющек), а не в ширину (много наследников одного базового класса), ООП — неверный выбор.
Здравствуйте, Shmj, Вы писали:
S>Или то же расширение, которое ООП решает механизмом наследования — показывает что это не удобно и что лучше не наследование (которого в Rust нет вовсе) — а агрегация.
Наследование считалось основной фишкой ООП лет 30 назад. Оно не хорошее и не плохое. Это инструмент, которым нужно уметь пользоваться.
Я насмотрелся, как наследуют один класс от другого только потому, что в базовом классе есть нужный метод. Я видел ситуации, когда нужно объявить объект не базового класса и создать что-то из производных, а объявить обпеременную строго определённого типа в иерархии классов. Потому что часть методов переопределяются, а часть — нет. Причём какие-то сразу, а какие-то позже. И от того, объект какого типа объявлен, зависит, переопределённый метод будет вызван или нет.
Лично я наследование реализации стараюсь не использовать. Го иногда оно вполне работает.
Здравствуйте, Doom100500, Вы писали:
D>Мне, например приходится работать с огромной иерархией, где долго нужно напрягаться, чтобы осознать кто от кого наследуется, и какая именно виртуальная функция вызовется. А если я вызываю базу, никто мне не расскажет, дойдёт ли это до самого верха, если я вручную не пройдусь по всей иерархии. Конечно, это кривой дизайн. Но он УЖЕ есть, и с ним надо жить. Вот тут ООП откровенно мешает.
S>1. Наследование — суть: как ПЕРЕИСПОЛЬЗОВАТЬ код без его копирования?
S> — композиция
S>2. Инкапсуляция — суть: Как ИЗОЛИРОВАТЬ части системы, чтобы изменения одной части не ЛОМали другие?
S> — модули в Rust
S>3. Полиморфизм — суть: Как ПИСАТЬ код, который работает с разными типами данных
S> — трейты в Rust
И что здесь нового? Достаточно прочитать GoF, чтобы стало понятно, что ООП это просто 3 паттерна, возведенные в абсолют, и то что есть паттерны, решающие аналогичные задачи. Что использовать уже зависит от языка и опыта.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Свободу Анжеле Девис и Юрию Деточкину, Вы писали:
САД>>когда-то в ооп было три принципа. E>Когда то было 7 принципов: E>
E>Я в свое время так на собеседованиях троллил, ибо от меня ожидалось что я 3 назову и других . Но 23 летние сеньеры чаще всего не могли оценить нестандартные ответы, правда мне пофиг было, я для тренировки на собеседования ходил. Сейчас увы, гуглить пришлось.
Тоже первый раз про 7 принципов слышу... Понял почему, потому что это цитата из Буча, а его надо сильно фильтровать
Здравствуйте, Shmj, Вы писали:
S>Этот чувак уже третье видео обоснованно унижает ООП:
и охота тебе тратить свое время на просмотры и прослушивания всякого бреда.
С ООП все просто. Оно великолепно тогда, когда твоя задача представляется в виде объектов и связей между ними.
Там, где не представляется, используются другие парадигмы программирования.
Натягивание же совы на глобус всегда приводит к разрыву и кончине совы.
