Ответы пользователя по тегу ООП
  • Правильно ли понял понятие - абстрактый метод?

    @UnformedVoid
    Разработчик ПО
    В принципе, верно.
    1) Абстрактный класс может иметь абстрактный метод — то есть метод без реализации
    2) Каждый прямой потомок абстрактного класса обязуется его реализовать
    Потомок потомка уже имеет дело с перегруженным методом, поэтому не обязан самостоятельно его реализовывать.
    Ответ написан
    2 комментария
  • Зачем нужно ООП?

    @UnformedVoid
    Разработчик ПО
    ООП задумывалось как подход для декомпозиции кода на модули — классы. Каждый класс выполняет свою функцию и код остаётся чистым. Это в идеале. Но в реале, ООП устраняя сложности процедурного программирования, добавляет свои. Всё как вы и описали. Идеи, описанные в книжках, в реальных примерах не имеют применений. Для написания хорошего ООП кода нужно много знать и хорошо понимать абстрактную сторону. Плюс, ООП реализовано множеством способов. Популярные реализации ООП (Java, C#) по-сути являются Класс-Ориентированным Программированием. Помимо этого ООП увеличивает объём кода. Также, постулаты на котором, основано текущее (популярное) ООП создают предпосылки для хрупкого кода. Например, наследование. Изначально наследование подразумевалось как метод для переиспользования кода. Но со временем стало понятно, что большие иерархии классов ведут к непредсказуемым ошибкам. Если обнаруживается ошибка в базовом классе при наличии уже большой иерархии, её исправление чревато появлением сложных ситуаций с падением модулей завязанных на него. Можно привести другие примеры, но это тема для целой статьи, а возможно и для нескольких. Сейчас в языки ООП внедряются фичи из функционального программирования. Функциональное программирование базируется на идее композиции функций. ООП сейчас переходит (или уже перешло) от наследования к композиции объектов. То есть рекомендуется использовать композицию вместо больших иерархий наследования. Функциональное программирование лишено проблем ООП. Многие вещи, которые в ООП надо специально изучать (например шаблоны проектирования, внедрение зависимостей), в ФП являются либо основополагающим принципом, либо естественно выплывающим следствием (в ООП тоже много хороших практик выплывают естественным образом, однако, чтоб понять их естественность приходится хорошенько вглядываться). ФП очень многое даёт из коробки. ООП — неплохая штука, однако оно отживает свой век. ФП позволяет с гораздо меньшими затратами писать надёжный, расширяемый, краткий, элегантный и эффективный код.

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