История изменений
Исправление kaldeon, (текущая версия) :
В классическом ООП выделяют четыре ключевых принципа: инкапсуляция, абстракция, наследование и полиморфизм.
Go не предлагает традиционные средства реализации ООП.
Но если говорить только о принципах, то всё-таки самым важным является абстракция.
Чем на Golang удобнее, чем на Си? Наличием интерфейсов?
Да.
Ты пытаешься представить композицию как какую-то инновацию в мире софтостроения?
Нет.
намного меньшее количество кода по сравнению с композицией
И это всё, вся проблема выбора сводится к количеству кода?
Преимущество композиции в большей гибкости и более естественном восприятии, тогда как при наследовании нужно тратить время на поиск схожестей и построение иерархии, что особенно затруднительно на ранних стадиях разработки.
Недостатки композиции решаются трейтами, миксинами, встраиванием типов.
Разве хорошо, что нет возможности более точно назначать права доступа к членам классов?
Нормально, никто не жалуется. Там, где действительно нужна инкапсуляция, её можно сделать через пакет.
Ах да, ведь в Golang нет даже классов …
А зачем они нужны?
Слияние с другими языками – понятная причина, но технически непримечательная.
В каком смысле слияние?
Быть похожим на все остальные. C#, PHP, Java, VB – они все предлагают примерно один и тот же стиль.
Исправление kaldeon, :
В классическом ООП выделяют четыре ключевых принципа
Go не предлагает традиционные средства реализации ООП.
Чем на Golang удобнее, чем на Си? Наличием интерфейсов?
Да.
Ты пытаешься представить композицию как какую-то инновацию в мире софтостроения?
Нет.
намного меньшее количество кода по сравнению с композицией
И это всё, вся проблема выбора сводится к количеству кода?
Преимущество композиции в большей гибкости и более естественном восприятии, тогда как при наследовании нужно тратить время на поиск схожестей и построение иерархии, что особенно затруднительно на ранних стадиях разработки.
Недостатки композиции решаются трейтами, миксинами, встраиванием типов.
Разве хорошо, что нет возможности более точно назначать права доступа к членам классов?
Нормально, никто не жалуется. Там, где действительно нужна инкапсуляция, её можно сделать через пакет.
Ах да, ведь в Golang нет даже классов …
А зачем они нужны?
Слияние с другими языками – понятная причина, но технически непримечательная.
В каком смысле слияние?
Быть похожим на все остальные. C#, PHP, Java, VB – они все предлагают примерно один и тот же стиль.
Исходная версия kaldeon, :
В классическом ООП выделяют четыре ключевых принципа
Go не предлагает традиционные средства реализации ООП.
Чем на Golang удобнее, чем на Си? Наличием интерфейсов?
Да. Это упрощает dynamic dispatch.
Ты пытаешься представить композицию как какую-то инновацию в мире софтостроения?
Нет.
намного меньшее количество кода по сравнению с композицией
И это всё, вся проблема выбора сводится к количеству кода?
Преимущество композиции в большей гибкости и более естественном восприятии, тогда как при наследовании нужно тратить время на поиск схожестей и построение иерархии, что особенно затруднительно на ранних стадиях разработки.
Недостатки композиции решаются трейтами, миксинами, встраиванием типов.
Разве хорошо, что нет возможности более точно назначать права доступа к членам классов?
Нормально, никто не жалуется. Там, где действительно нужна инкапсуляция, её можно сделать через пакет.
Ах да, ведь в Golang нет даже классов …
А зачем они нужны?
Слияние с другими языками – понятная причина, но технически непримечательная.
В каком смысле слияние?
Быть похожим на все остальные. C#, PHP, Java, VB – они все предлагают примерно один и тот же стиль.