История изменений
Исправление kaldeon, (текущая версия) :
> смотрят вот на этот пример [1] как на ужаснах.
“Yeah, well, you know, that’s just, like, your opinion, man.”
> десктопного GUI
Безосновательно.
> Вот только есть ощущение, что основное применение Go – это микросервисы по перекладыванию джейсонов. И миллионы строк складываются из сотен мелких проектах, которые никогда не линкуются в один исполнимый файл. В отличии от проектов на C++/Java/C# и пр.
moby [2] — микросервис? А там <2M непустых строк кода.
И что плохого в микросервисах, перекладывающих джейсоны? (Хотя скорее gRPC + Kafka.)
Ну вот я на прошлой работе успел поработать год. Те 13 проектов, которые я себе склонировал, насчитывают <0.8M непустых строк. И это я видел только вершину айсберга.
Go, кстати, компилируется быстрее C++. От 10 до 100 раз быстрее.
> Если для решения одной и той же задачи на простом языке нужно написать x5 строк по сравнению с решением на более сложном языке, то простота и минималистичность становятся не достоинством, а отягчающим фактором.
«x5» — это очевидное преувеличение. Если так относиться в штыки к количеству строк, то по такой логике нужно писать на APL.
Читаемость ≠ сжатость.
> Я уже не настолько молод чтобы тратить время на поиск эвфемизмов для «малолетних дебилов»
Я не думаю, что вы способны судить о чужом возрасте.
> > Гайдлайны разве не пишутся для дебилов?
> Зависит от языка и его пользователей.
То был ироничный вопрос. Типа, если вы допускаете наличие гайдлайнов для C++, в чём проблема одного общего гайдлайна в Go?
Ну допустим язык предлагает широкие возможности и аудиторию программистов. Гайдлайн нужен объективно, чтобы склеить эту разнородную массу. Go решает эту проблему на уровне языка. В чём проблема?
В том, что язык ограничен возможностями и аудитория сужена? Но ведь мы сами решали эту задачу. Циклический тупик, короче.
> вносят слишком большой оверхед и/или непредсказуемость, критичную для предметной области (например, исключения в коде real-time проектов);
Значит вы осознаёте допустимость ограничений возможностей. А сможете тогда объяснить, почему в одном случае это оправдано, а в другом нет? Двойной стандарт какой-то.
Ну типа исключений нет в Go, но мы тоже хотим иметь большую предсказуемость по части обработки ошибок. Да, цена одной ошибки не велика, но она накапливается на объёмах крупномасштабной разработки.
> Ну так какую проблему вы видете в данном паттерне и как ваши костыли от нее защищают?
Проблема в том, что при наследовании нет чёткой границы между контрактом и деталями реализации.
Допустим, base.do_something владеет неким счётчиком base.something_count и мы его также используем в derived_one.do_specific_action. Это нарушает инкапсуляцию [sny86], но какая нам разница, мы же этого и добиваемся.
Внезапно, в не столь отдалённом будущем, base.do_something меняет смысл счётчика. Добавляет какое-нибудь условие.
Итог: контракт не нарушен, но дочерние классы сломались.
В случае с композицией у нас нет данной проблемы, потому что контракт и детали реализации никогда не смешиваются в единое целое.
В случае с наследованием у нас единственный надёжный выход: полный запрет доступа к реализации, что встречается редко и очень близко к композиции.
[1]: Что происходит с популярностью Go? (комментарий)
[2]: https://github.com/moby/moby
[sny86]: Alan Snyder. Encapsulation and inheritance in object-oriented languages.
Исходная версия kaldeon, :
> смотрят вот на этот пример [1] как на ужаснах.
“Yeah, well, you know, that’s just, like, your opinion, man.”
> десктопного GUI
Безосновательно.
> Вот только есть ощущение, что основное применение Go – это микросервисы по перекладыванию джейсонов. И миллионы строк складываются из сотен мелких проектах, которые никогда не линкуются в один исполнимый файл. В отличии от проектов на C++/Java/C# и пр.
moby [2] — микросервис? А там <2M непустых строк кода.
И что плохого в микросервисах, перекладывающих джейсоны? (Хотя скорее gRPC + Kafka.)
Ну вот я на прошлой работе успел поработать год. Те 13 проектов, которые я себе склонировал, насчитывают <0.8M непустых строк. И это я видел только вершину айсберга.
> Если для решения одной и той же задачи на простом языке нужно написать x5 строк по сравнению с решением на более сложном языке, то простота и минималистичность становятся не достоинством, а отягчающим фактором.
«x5» — это очевидное преувеличение. Если так относиться в штыки к количеству строк, то по такой логике нужно писать на APL.
Читаемость ≠ сжатость.
> Я уже не настолько молод чтобы тратить время на поиск эвфемизмов для «малолетних дебилов»
Я не думаю, что вы способны судить о чужом возрасте.
> > Гайдлайны разве не пишутся для дебилов?
> Зависит от языка и его пользователей.
То был ироничный вопрос. Типа, если вы допускаете наличие гайдлайнов для C++, в чём проблема одного общего гайдлайна в Go?
Ну допустим язык предлагает широкие возможности и аудиторию программистов. Гайдлайн нужен объективно, чтобы склеить эту разнородную массу. Go решает эту проблему на уровне языка. В чём проблема?
В том, что язык ограничен возможностями и аудитория сужена? Но ведь мы сами решали эту задачу. Циклический тупик, короче.
> вносят слишком большой оверхед и/или непредсказуемость, критичную для предметной области (например, исключения в коде real-time проектов);
Значит вы осознаёте допустимость ограничений возможностей. А сможете тогда объяснить, почему в одном случае это оправдано, а в другом нет? Двойной стандарт какой-то.
Ну типа исключений нет в Go, но мы тоже хотим иметь большую предсказуемость по части обработки ошибок. Да, цена одной ошибки не велика, но она накапливается на объёмах крупномасштабной разработки.
> Ну так какую проблему вы видете в данном паттерне и как ваши костыли от нее защищают?
Проблема в том, что при наследовании нет чёткой границы между контрактом и деталями реализации.
Допустим, base.do_something владеет неким счётчиком base.something_count и мы его также используем в derived_one.do_specific_action. Это нарушает инкапсуляцию [sny86], но какая нам разница, мы же этого и добиваемся.
Внезапно, в не столь отдалённом будущем, base.do_something меняет смысл счётчика. Добавляет какое-нибудь условие.
Итог: контракт не нарушен, но дочерние классы сломались.
В случае с композицией у нас нет данной проблемы, потому что контракт и детали реализации никогда не смешиваются в единое целое.
В случае с наследованием у нас единственный надёжный выход: полный запрет доступа к реализации, что встречается редко и очень близко к композиции.
[1]: Что происходит с популярностью Go? (комментарий)
[2]: https://github.com/moby/moby
[sny86]: Alan Snyder. Encapsulation and inheritance in object-oriented languages.