История изменений
Исправление Aber, (текущая версия) :
Если контрол вызывает метод, то в этом методе мы можем использовать поля класса,
Инкапсуляция это только один из признаков ООП, доступно во многих языках не считающихся ООП. Фактически это ведь просто создание структур и связанных с ними функций.
чтобы сообщить информацию остальной программе. Если бы мы использовали просто функцию, то пришлось бы задействовать глобальные переменные
Остальной программе через установку глобального состояния тем или иным способом. ООП тут не требуется, а когда нужно то используют такой анти-паттерн как синглетон. Как бы выбора нет, либо синглетон, либо глобальный контекст который рассовывают везде (очень много ненужного когда, зато никаких скрытых состояний). В общем я не вижу чем тут ООП сильно помогает.
В моём разборе работы фреймворков никакие абстракции не потребовались. Нужен конкретный пример, где они требуются.
В любом где фреймворк оперирует глобальным состоянием и ожидает от пользователя фреймворка только списки указателей на функции. Когда в программе будет достигнуто то одно то другое состояние будут вызваться подходящие функции из предоставленных списков. Вот он чистый Inversion of control.
Из описания понятно что ООП как бы и не нужно, нужны только указатели на функции или любое техническое решение позволяющее делать dynamic dispatch.
Если взять тот же rust (который я не знаю) то он позволяет практически все это, и инкапсуляцию, и dynamic dispatch, и отделение абстракций от реализаций, там только нет наследования которое как бы и не нужно.
В ООП языках все больше и больше отказываются от иерархий классов, большая иерархия легко порождает проблему fragile base class. Насколько я понимаю эту проблему пытаются таргетировать внедрением SOLID где следование принципу под буковой L должно было бы её решить, только пишут программы не так.
В общем если сравнивать с современными языками то ООП как бы и не особо нужно, потому как основные элементы ООП в других языках уже есть, а «не имеющие аналогов» иерархии классов нафиг никому не вперлись.
Так что если тебе не нужно ООП то оно тебе не нужно, а если понадобиться то ты его можешь воспроизвести в той или иной степени на любом языке.
Исходная версия Aber, :
Если контрол вызывает метод, то в этом методе мы можем использовать поля класса,
Инкапсуляция это только один из признаков ООП, доступно во многих языках не считающихся ООП. Фактически это ведь просто создание структур и связанных с ними функций.
чтобы сообщить информацию остальной программе. Если бы мы использовали просто функцию, то пришлось бы задействовать глобальные переменные
Остальной программе через установку глобального состояния тем или иным способом. ООП тут не требуется, а когда нужно то используют такой анти-паттерн как синглетон. Как бы выбора нет, либо сингретон, либо глобальный контекст который рассовывают везде (очень много ненужного когда, зато никаких скрытых состояний). В общем я не вижу чем тут ООП сильно помогает.
В моём разборе работы фреймворков никакие абстракции не потребовались. Нужен конкретный пример, где они требуются.
В любом где фреймворк оперирует глобальным состоянием и ожидает от пользователя фреймворка только списки указателей на функции. Когда в программе будет достигнуто то одно то другое состояние будут вызваться подходящие функции из предоставленных списков. Вот он чистый Inversion of control.
Из описания понятно что ООП как бы и не нужно, нужны только указатели на функции или любое техническое решение позволяющее делать dynamic dispatch.
Если взять тот же rust (который я не знаю) то он позволяет практически все это, и инкапсуляцию, и dynamic dispatch, и отделение абстракций от реализаций, там только нет наследования которое как бы и не нужно.
В ООП языках все больше и больше отказываются от иерархий классов, большая иерархия легко порождает проблему fragile base class. Насколько я понимаю эту проблему пытаются таргетировать внедрением SOLID где следование принципу под буковой L должно было бы её решить, только пишут программы не так.
В общем если сравнивать с современными языками то ООП как бы и не особо нужно, потому как основные элементы ООП в других языках уже есть, а «не имеющие аналогов» иерархии классов нафиг никому не вперлись.
Так что если тебе не нужно ООП то оно тебе не нужно, а если понадобиться то ты его можешь воспроизвести в той или иной степени на любом языке.