История изменений
Исправление kaldeon, (текущая версия) :
> парадигма Go и всяких там рустов - не ООП. а контрактное програмирование начального уровня.
Я не знаю что такое контрактное программирование. Design by Contract [1]? Если да, то DbC относится к наследованию реализации примерно так же, как и принцип подстановки Лисков.
Принцип Лисков очень важен (и вполне применим в Go), но ограничен. Он укрепляет дизайн поведения, но не может решить проблемы привязки к деталям реализации, хрупкого базового класса или преждевременной жёсткой иерархии.
> Контракты [интерфейс] нужно реализовать
Не нужно. Объект может не иметь ни одной реализации интерфейса и он не перестаёт быть объектом.
(Объект — единица, связывающая данные и функции, состояние и поведение. Конкретно в Go объект связывает *тип* и функции.)
(Я это говорю, в основном, чтобы ответить на следующий пункт.)
> указатель на обьект(один указатель) из кондового ООП симулируется парой - указатель на структуру + указатель на контракт
Объект в Go — это единственное значение и не обязательно указатель. Только значения интерфейсного типа имеют структуру «указатель на данные + указатель на контракт».
> кондового ООП, по понятиям, там нет. в кондовом ООП класс есть замкнутая, целостная дефиниция содержащая как данные, так и реализации контрактов класса.
В Go это есть, «по понятию» точно, просто другой синтаксис.
> и это прекрасно в силу лексической инкапсуляции - наружу ничто не торчит, и не может быть вызвано или использовано, если не надо(внутренние константы, типы, функции и все такое).
В Go есть контроль доступа — на уровне пакета.
> все находится вперемешку, собирается читателем вместе только тщательной читкой
Беспорядок бывает разный:
1. Когда предметы разной природы объединены в одну группу
2. Когда предметы одной природы разъединены по разным группам
Использование файлов для организации позволяет бороться с обеими пунктами. А вот классы, особенно если руководствоваться подходом «всё есть класс», усугубляют беспорядок второго пункта. Не думаю, что пакет из 200 классов на файл — это порядок.
Я лично не вижу как классы обеспечивают или упрощают наведение порядка.
А вот файлы я бы сказал лучше подходят для этой роли. Они гибче. Файл — именованный контейнер, ни больше ни меньше. Не нужно выходить на более высокий уровень и думать «а действительно ли данный компонент имеет такое-то и такое отношение к данному компоненту». Просто группируешь по сходству, что быстро и всегда своевременно.
> можно ошибочно прочитать байндинг, как принадлежащий другой структуре
По крайне мере правильное название структуры перед глазами. Можно очень быстро вернуться в случае ошибки. А вот если мы работаем с Java-подобным синтаксисом, то пришлось бы скакануть наверх, чтобы вспомнить.
Java решает эту проблему вынесением названия класса в файл. Но лексическая проблема остаётся.
> представим ужасный случай, когда у вас несколько языков, каждый со своим гайдлайном. это снова лишняя когнитивная нагрузка на разработчика и архитектора.
Эта проблема в любом случае будет, является ли стиль Go навязанным или нет. А приближать стили разных языков к одному знаменателю — ну такое себе. Получится как в той шутке, где в Си убрали все скобки вправо и сделали его «Питоном».
Вообще, большая проблема в осознанной нагрузке, когда приходится сделать паузу, обратить на внимание на какую-нибудь мелочь, принять решение. И эта проблема прекрасно решается через gofmt: любой код на этом языке практически гарантированно будет написан в едином стиле, сокращая период привыкания под ноль.
Нагрузка на архитектора решается тем, что ему вообще не нужно думать про форматирование. Нужно всего-лишь принять стиль gofmt на веру. Это куда эффективнее, чем в каждом проекте тратить время на то, где лучше поставить запятую.
Исправление kaldeon, :
> парадигма Go и всяких там рустов - не ООП. а контрактное програмирование начального уровня.
Я не знаю что такое контрактное программирование. Design by Contract [1]? Если да, то DbC относится к наследованию реализации примерно так же, как и принцип подстановки Лисков.
Принцип Лисков очень важен (и вполне применим в Go), но ограничен. Он укрепляет дизайн поведения, но не может решить проблемы привязки к деталям реализации, хрупкого базового класса или преждевременной жёсткой иерархии.
> Контракты [интерфейс] нужно реализовать
Не нужно. Объект может не иметь ни одной реализации интерфейса и он не перестаёт быть объектом.
(Объект — единица, связывающая данные и функции, состояние и поведение. Конкретно в Go объект связывает *тип* и функции.)
(Я это говорю, в основном, чтобы ответить на следующий пункт.)
> указатель на обьект(один указатель) из кондового ООП симулируется парой - указатель на структуру + указатель на контракт
Объект в Go — это единственное значение и не обязательно указатель. Только значения интерфейсного типа имеют структуру «указатель на данные + указатель на контракт».
> кондового ООП, по понятиям, там нет. в кондовом ООП класс есть замкнутая, целостная дефиниция содержащая как данные, так и реализации контрактов класса.
В Go это есть, «по понятию» точно, просто другой синтаксис.
> и это прекрасно в силу лексической инкапсуляции - наружу ничто не торчит, и не может быть вызвано или использовано, если не надо(внутренние константы, типы, функции и все такое).
В Go есть контроль доступа — на уровне пакета.
> все находится вперемешку, собирается читателем вместе только тщательной читкой
Беспорядок бывает разный:
1. Когда предметы разной природы объединены в одну группу
2. Когда предметы одной природы разъединены по разным группам
Использование файлов для организации позволяет бороться с обеими пунктами. А вот классы, особенно если руководствоваться подходом «всё есть класс», усугубляют беспорядок второго пункта. Не думаю, что пакет из 200 классов на файл — это порядок.
Я лично не вижу как классы обеспечивают или упрощают наведение порядка.
А вот файлы я бы сказал лучше подходят для этой роли. Файл — именованный контейнер, ни больше ни меньше. Не нужно выходить на более высокий уровень и думать «а действительно ли данный компонент имеет такое-то и такое отношение к данному компоненту». Просто группируешь по сходству, что быстро и всегда своевременно.
> можно ошибочно прочитать байндинг, как принадлежащий другой структуре
По крайне мере правильное название структуры перед глазами. Можно очень быстро вернуться в случае ошибки. А вот если мы работаем с Java-подобным синтаксисом, то пришлось бы скакануть наверх, чтобы вспомнить.
Java решает эту проблему вынесением названия класса в файл. Но лексическая проблема остаётся.
> представим ужасный случай, когда у вас несколько языков, каждый со своим гайдлайном. это снова лишняя когнитивная нагрузка на разработчика и архитектора.
Эта проблема в любом случае будет, является ли стиль Go навязанным или нет. А приближать стили разных языков к одному знаменателю — ну такое себе. Получится как в той шутке, где в Си убрали все скобки вправо и сделали его «Питоном».
Вообще, большая проблема в осознанной нагрузке, когда приходится сделать паузу, обратить на внимание на какую-нибудь мелочь, принять решение. И эта проблема прекрасно решается через gofmt: любой код на этом языке практически гарантированно будет написан в едином стиле, сокращая период привыкания под ноль.
Нагрузка на архитектора решается тем, что ему вообще не нужно думать про форматирование. Нужно всего-лишь принять стиль gofmt на веру. Это куда эффективнее, чем в каждом проекте тратить время на то, где лучше поставить запятую.
Исправление kaldeon, :
> парадигма Go и всяких там рустов - не ООП. а контрактное програмирование начального уровня.
Я не знаю что такое контрактное программирование. Design by Contract [1]? Если да, то DbC относится к наследованию реализации примерно так же, как и принцип подстановки Лисков.
Принцип Лисков очень важен (и вполне применим в Go), но ограничен. Он укрепляет дизайн поведения, но не может решить проблемы привязки к деталям реализации, хрупкого базового класса или преждевременной жёсткой иерархии.
> Контракты [интерфейс] нужно реализовать
Не нужно. Объект может не иметь ни одной реализации интерфейса и он не перестаёт быть объектом.
(Объект — единица, связывающая данные и функции, состояние и поведение. Конкретно в Go объект связывает *тип* и функции.)
(Я это говорю, в основном, чтобы ответить на следующий пункт.)
> указатель на обьект(один указатель) из кондового ООП симулируется парой - указатель на структуру + указатель на контракт
Объект в Go — это единственное значение и не обязательно указатель. Только значения интерфейсного типа имеют структуру «указатель на данные + указатель на контракт».
> кондового ООП, по понятиям, там нет. в кондовом ООП класс есть замкнутая, целостная дефиниция содержащая как данные, так и реализации контрактов класса.
В Go это есть, «по понятию» точно, просто другой синтаксис.
> и это прекрасно в силу лексической инкапсуляции - наружу ничто не торчит, и не может быть вызвано или использовано, если не надо(внутренние константы, типы, функции и все такое).
В Go есть лексический контроль доступа — на уровне пакета.
> все находится вперемешку, собирается читателем вместе только тщательной читкой
Беспорядок бывает разный:
1. Когда предметы разной природы объединены в одну группу
2. Когда предметы одной природы разъединены по разным группам
Использование файлов для организации позволяет бороться с обеими пунктами. А вот классы, особенно если руководствоваться подходом «всё есть класс», усугубляют беспорядок второго пункта. Не думаю, что пакет из 200 классов на файл — это порядок.
Я лично не вижу как классы обеспечивают или упрощают наведение порядка.
А вот файлы я бы сказал лучше подходят для этой роли. Файл — именованный контейнер, ни больше ни меньше. Не нужно выходить на более высокий уровень и думать «а действительно ли данный компонент имеет такое-то и такое отношение к данному компоненту». Просто группируешь по сходству, что быстро и всегда своевременно.
> можно ошибочно прочитать байндинг, как принадлежащий другой структуре
По крайне мере правильное название структуры перед глазами. Можно очень быстро вернуться в случае ошибки. А вот если мы работаем с Java-подобным синтаксисом, то пришлось бы скакануть наверх, чтобы вспомнить.
Java решает эту проблему вынесением названия класса в файл. Но лексическая проблема остаётся.
> представим ужасный случай, когда у вас несколько языков, каждый со своим гайдлайном. это снова лишняя когнитивная нагрузка на разработчика и архитектора.
Эта проблема в любом случае будет, является ли стиль Go навязанным или нет. А приближать стили разных языков к одному знаменателю — ну такое себе. Получится как в той шутке, где в Си убрали все скобки вправо и сделали его «Питоном».
Вообще, большая проблема в осознанной нагрузке, когда приходится сделать паузу, обратить на внимание на какую-нибудь мелочь, принять решение. И эта проблема прекрасно решается через gofmt: любой код на этом языке практически гарантированно будет написан в едином стиле, сокращая период привыкания под ноль.
Нагрузка на архитектора решается тем, что ему вообще не нужно думать про форматирование. Нужно всего-лишь принять стиль gofmt на веру. Это куда эффективнее, чем в каждом проекте тратить время на то, где лучше поставить запятую.
Исходная версия kaldeon, :
> парадигма Go и всяких там рустов - не ООП. а контрактное програмирование начального уровня.
Я не знаю что такое контрактное программирование. Design by Contract [1]? Если да, то DbC относится к наследованию реализации примерно так же, как и принцип подстановки Лисков.
Принцип Лисков очень важен (и вполне применим в Go), но ограничен. Он укрепляет дизайн поведения, но не может решить проблемы привязки к деталям реализации, хрупкого базового класса или преждевременной жёсткой иерархии.
> Контракты [интерфейс] нужно реализовать
Не нужно. Объект может не иметь ни одной реализации интерфейса и он не перестаёт быть объектом.
(Объект — единица, связывающая данные и функции, состояние и поведение. Конкретно в Go объект связывает *тип* и функции.)
(Я это говорю, в основном, чтобы ответить на следующий пункт.)
> указатель на обьект(один указатель) из кондового ООП симулируется парой - указатель на структуру + указатель на контракт
Объект в Go — это единственное значение и не обязательно указатель. Только значения интерфейсного типа имеют структуру «указатель на данные + указатель на контракт».
> кондового ООП, по понятиям, там нет. в кондовом ООП класс есть замкнутая, целостная дефиниция содержащая как данные, так и реализации контрактов класса.
Мне кажется, в Go всё это есть, «по понятию» точно. Просто другой синтаксис.
> и это прекрасно в силу лексической инкапсуляции - наружу ничто не торчит, и не может быть вызвано или использовано, если не надо(внутренние константы, типы, функции и все такое).
В Go есть лексический контроль доступа — на уровне пакета.
> все находится вперемешку, собирается читателем вместе только тщательной читкой
Беспорядок бывает разный:
1. Когда предметы разной природы объединены в одну группу
2. Когда предметы одной природы разъединены по разным группам
Использование файлов для организации позволяет бороться с обеими пунктами. А вот классы, особенно если руководствоваться подходом «всё есть класс», усугубляют беспорядок второго пункта. Не думаю, что пакет из 200 классов на файл — это порядок.
Я лично не вижу как классы обеспечивают или упрощают наведение порядка.
А вот файлы я бы сказал лучше подходят для этой роли. Файл — именованный контейнер, ни больше ни меньше. Не нужно выходить на более высокий уровень и думать «а действительно ли данный компонент имеет такое-то и такое отношение к данному компоненту». Просто группируешь по сходству, что быстро и всегда своевременно.
> можно ошибочно прочитать байндинг, как принадлежащий другой структуре
По крайне мере правильное название структуры перед глазами. Можно очень быстро вернуться в случае ошибки. А вот если мы работаем с Java-подобным синтаксисом, то пришлось бы скакануть наверх, чтобы вспомнить.
Java решает эту проблему вынесением названия класса в файл. Но лексическая проблема остаётся.
> представим ужасный случай, когда у вас несколько языков, каждый со своим гайдлайном. это снова лишняя когнитивная нагрузка на разработчика и архитектора.
Эта проблема в любом случае будет, является ли стиль Go навязанным или нет. А приближать стили разных языков к одному знаменателю — ну такое себе. Получится как в той шутке, где в Си убрали все скобки вправо и сделали его «Питоном».
Вообще, большая проблема в осознанной нагрузке, когда приходится сделать паузу, обратить на внимание на какую-нибудь мелочь, принять решение. И эта проблема прекрасно решается через gofmt: любой код на этом языке практически гарантированно будет написан в едином стиле, сокращая период привыкания под ноль.
Нагрузка на архитектора решается тем, что ему вообще не нужно думать про форматирование. Нужно всего-лишь принять стиль gofmt на веру. Это куда эффективнее, чем в каждом проекте тратить время на то, где лучше поставить запятую.