Когда ООП поможет вам?
ฝัง
- เผยแพร่เมื่อ 6 ก.ย. 2015
- Объектно-Ориентированное Программирование - это не панацея, которая позволит вам всегда разрабатывать приложения правильно. Иногда подойдёт старый добрый структурный подход, или даже простое последовательное исполнение.
Но как решить нужен вам ООП или нет? В этом видео я привожу 3 вопроса, которые вы можете себе задать о конкретном проекте, и эти вопросы позволят вам начать думать в нужном русле и выбрать подход максимально подходящий под требования клиента.
Господи исусе!
Первое доходчивое объяснение. Спасибо
Володя, добрый день. Спасибо за ваши видео - очень доходчиво объясняете.Скажите, планируется ли видео о полиморфизме? Этот вопрос, на сколько я понимаю, актуален и по сей день.
Вообщем такая проблема, смотрю ваши ролики и не могу остановиться, что делать то?
Это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь
И это Господь, Господь
И Иисус Христос, Господь
Спасибо за видос. Вот ищу информацию, но всё равно не понимаю зачем нужно ооп. Кажется, что и до него уже всё было.
Ядро linux миллионы строк кода, СИ, динамично, как-то обошлись без ООП
В ядре линукса куча ООП, реализованного средствами си.
Си может в ООП. Там структурки есть. У них есть наследование. Даже полиморфизм можно.
@@user-lz1yb6qk3f Костыльное. И далеко не везде. Там действительно миллионы строк без ооп
@@Shpinog И что это доказывает? Что ООП не нужно?
@@kvidon1357 А где-то написано, что не нужно? Нужно не нужно это субьективщина
тут немного на молодого столлмана похож ))
ООП обратно пропорционально продуктивно пониманию алгоритма в целом ))) все всегда стремиться к одному универсальному объекту а ООП с 1 Объектом это уже не ООП ))))
+Тимур Абдулов Кто всегда стремиться к одному универсальному объекту?
+Vladimir Mozhenkov наука вообщем и программирование в частности в роли такого грааля так сказать эталона универсальности объекта выступает ИИ ну и вообще если углубляться в вопрос не тока программирования это касается
+Vladimir Mozhenkov существует ли множество включающие все множества )))
Vladimir Mozhenkov да я так как бы любитель просто свое мнение как бы высказываю я может и ошибся я не знаю )))
@@user-zb5pr4wv8d ну что, поменялось мнение?
Привет Володя. А я Андрей и я алкоголик....
А где полиморфизм?
Лайк тебе, говорящая борода. Хоть бы обмолвился, какие языки ооп, а какие нет.
я даже не вижу разницы между классом и функцией :(. Кто может подсказать на реальном примере в чем преимущество ооп?
вот это ты заявил
это сильно
Класс это данные и работа с этими данными. Данные сохраняют состояние экземпляра класса, а функции в классе позволяют работать с экземпляром на основании этого состояния.
А функция это просто работа с данными
Мне кажется или в конце видео , за кадром, чайник закипел ?))
Опять ООП-неофиты. Все что можно сделать в ООП можно сделать и процедурно. Если ты не умеешь писать программу модульно и за разбивать на предметную область то и ООП тебе ничем не поможет (ну кроме того что на первых этапах ты тупо соберешь некоторые схожие функции в кучу, но потом увидишь, что не всегда это верно).
ООП себя очень хорошо чувствует в сущностях, когда нужно множество объектов с одного класса (например класс работы с файлом, или окно на рабочем столе, или фигура). В процедурном стиле это будет выглядеть как функция с +1 аргументом (неким дескриптором типа this) :)
Но все это не важно, сейчас стало очень распространена анемичная модель, когда данные "тонкие" и их передаю сервисам для обработки, которые не имеют внутренних состояний - ничего не напоминает? То есть это и есть процедурный стиль, люди опять пришли к тому что интуитивно правильно, но только через монструозный ООП, с тучей слоев (где наверно половина кода ничего не делает, а обслуживает работу сотни классов между собой). Такая же ситуация с дроблением классов на мелкие части, чуть ли не до пару методов.
И это все весело :)
Проблема процедурного подхода в том, что для инкапсуляции данных, программист должен знать о существования этой инкапсуляции (быть достаточного уровня квалифицирован и уметь писать модульные программы), то есть в процедурном языке нужно иметь соглашения для построение модульной программы (в ооп кстати тоже, как писали открытые свойства-класса так и пишут).
+Евгений Гикс все верно, но вот на самом в ООП проще все делать если конечно хорошо понимаешь что делаешь, хороший пример игра с животными в основе лежит один класс из него получаем еще класс - после полученный делим еще на несколько классов - красота !
что мешает сделать так?
//прыгнуть(хомяк, 10 метров);
Захотим чтобы хомяк полетел, мы просто перегрузим функцию
//лететь(хомяк, верх);
Никаких наследование - хотим летаем хотим нет.
А теперь ООП:
//Ручка.писать(тетрадь);
//Тетрадь.записать(ручка);
Вот и ломай голову. :D когда логично
//записать(ручка, тетрадь);
+Евгений Гикс хм, странный ютьюб, ответил человеку, а его поста нет :)
Евгений Гикс я тут =)
+Евгений Гикс Не совсем согласен с вами. Володя говорит, что ему нравиться создавать новые типы данных для решения некоторых задач.Представьте себе некий тип данных, который будет содержать операции для изменения внутреннего состояния. Это же очень хорошо ложиться на парадигму ООП. Программист создает новый тип данных, внутри типа данных реализован механизм манипуляции с этими данными.