История изменений

Адепты класс-ориентированного программирования с ноги запихивают методы работы с объектами в сами объекты, и делают вид, что так понимать код стало проще

Методы обеспечивают динамическую диспетчеризацию вызова по таблице методов объекта слева. Там, где она (диспетчеризация) вам нужна — используйте. Там, где не нужна — не используйте. Всё логично. Есть задача, есть под неё инструмент

Типовая проблема с твоим подходом — это когда я абсолютно точно знаю тип значения и мне не нужна динамическая диспетчеризация.

В JS по этой причине очень часто можно увидеть строки вроде Array.prototype.map.call(value...) или чуть покороче [].map.call(value...). Второй подход к решению проблемы статической диспетчеризации, который можно часто увидеть в стандартной библиотеке CPython — это пересоздание объекта через конструктор конкретного типа, например:

def somefunc(argument):
    val = str(argument)
    ...

Это, на самом деле, и является основной целью статической типизации, то есть, внесение предсказуемости в поведение моего кода, чтобы я был уверен, что мой код будет работать так, как я его написал и оттестировал, а не так, как в него передадут аргументы. Короче говоря, изоляция областей ответственности и локальное тестирование, или еще короче — модульность. По этой причине, например, CPython является языком со слабой модульностью, хотя, казалось бы, модули в нем есть — но они там только для виду и больше похожи на динамически подгружаемые строки кода, аля os = eval(open("os.py")). Как это когда-то делалось и в JS, пока в ES2015 не ввели настоящие модули.

И нет, статическая типизация сделана не ради рефакторинга. Рефакторинг является бессмысленной затеей, которая возникла прежде всего из-за большого объема ручной работы, требуемой для рефакторинга жавы. Потому рефакторинг является недостатком языка, а не его преимуществом. Грамотно написанный проект на языке программирования вместо жавы не требует длинного автоматического рефакторинга, чаще требуя ручного вдумчивого вмешательства, где статическая типизация уже не играет серьезной роли.

Ты заметил, что классы не помогают решать эту проблему? Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом.

https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

Это абстрактное исследование в вакууме показало, что 65-93% всех вызовов методов, как правило, вызывают только один-единственный статичный метод. Попытка сделать весь язык вокруг диспетчеризации по одному аргументу значит, что язык строится вокруг 13-32% всех вызовов в программах. Причем, проблема диспетчеризации по нескольким аргументам, как правило, в таких языках не решена вообще никак, таким образом отправляя эти 3-7% вызовов методов на костыли и «паттерны программирования».

На практике в архитектуре мы имеем дело не с числами, а со всякими плагинами, виджетами, менеджерами, менеджерами менеджеров, абстракциями над объектами БД и т.п. Всему этому нужна динамическая диспетчеризация

У тебя «преждевременная диспетчеризация». В большинстве случаев она не нужна, но сложно угадать, когда пригодится. Правда, с таким же успехом тебе может понадобится диспетчеризация по нескольким аргументам — и что ты тогда делать будешь?

Это проблема невротичного ума, а не классов. Читайте книги по архитектуре кода, там все эти типовые ошибки рассматриваются, когда в класс суют не то, что к нему относится

Подразумеваешь, что я эту парашу еще не читал. По факту, если ты посмотришь на реальные достаточно крупные проекты, то результат один: огромный базовый god object с методами на все случаи жизни, от которого наследуются мелкие конкретные реализации. Ну и где твои авторы книжек? Как правило, они выдают не связанные с реальность примеры, выдуманные плюшевые сложности, которые автор с легкостью решает своим тонким и прозорливым умом. Но по факту этот автор за свою жизнь не написал больше 10 тысяч строк, однако же, учит тебя писать сложные системы.

Адепты класс-ориентированного программирования с ноги запихивают методы работы с объектами в сами объекты, и делают вид, что так понимать код стало проще

Методы обеспечивают динамическую диспетчеризацию вызова по таблице методов объекта слева. Там, где она (диспетчеризация) вам нужна — используйте. Там, где не нужна — не используйте. Всё логично. Есть задача, есть под неё инструмент

Типовая проблема с твоим подходом — это когда я абсолютно точно знаю тип значения и мне не нужна динамическая диспетчеризация.

В JS по этой причине очень часто можно увидеть строки вроде Array.prototype.map.call(value...) или чуть покороче [].map.call(value...). Второй подход к решению проблемы статической диспетчеризации, который можно часто увидеть в стандартной библиотеке CPython — это пересоздание объекта через конструктор конкретного типа, например:

def somefunc(argument):
    val = str(argument)
    ...

Это, на самом деле, и является основной целью статической типизации, то есть, внесение предсказуемости в поведение моего кода, чтобы я был уверен, что мой код будет работать так, как я его написал и оттестировал, а не так, как в него передадут аргументы. Короче говоря, изоляция областей ответственности и локальное тестирование, или еще короче — модульность. По этой причине, например, CPython является языком со слабой модульностью, хотя, казалось бы, модули в нем есть — но они там только для виду и больше похожи на динамически подгружаемые строки кода, аля os = eval(open("os.py")). Как это когда-то делалось и в JS, пока в ES2015 не ввели настоящие модули.

И нет, статическая типизация сделана не ради рефакторинга. Рефакторинг является бессмысленной затеей, которая возникла прежде всего из-за большого объема ручной работы, требуемой для рефакторинга жавы. Потому рефакторинг является недостатком языка, а не его преимуществом. Грамотно написанный проект на языке программирования вместо жавы не требует длинного автоматического рефакторинга, чаще требуя ручного вдумчивого вмешательства, где статическая типизация уже не играет серьезной роли.

Ты заметил, что классы не помогают решать эту проблему? Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом.

https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

Это абстрактное исследование в вакууме показало, что 65-93% всех вызовов методов, как правило, вызывают только один-единственный статичный метод. Попытка сделать весь язык вокруг диспетчеризации по одному аргументу значит, что язык строится вокруг 13-32% всех вызовов в программах. Причем, проблема диспетчеризации по нескольким аргументам, как правило, в таких языках не решена вообще никак, таким образом отправляя эти 3-7% вызовов методов на костыли и «паттерны программирования».

На практике в архитектуре мы имеем дело не с числами, а со всякими плагинами, виджетами, менеджерами, менеджерами менеджеров, абстракциями над объектами БД и т.п. Всему этому нужна динамическая диспетчеризация

У тебя «преждевременная диспетчеризация». В большинстве случаев она не нужна, но сложно угадать, когда пригодится. Правда, с таким же успехом тебе может понадобится диспетчеризация по нескольким аргументам — и что ты тогда делать будешь?

Это проблема невротичного ума, а не классов. Читайте книги по архитектуре кода, там все эти типовые ошибки рассматриваются, когда в класс суют не то, что к нему относится

Подразумеваешь, что я эту парашу еще не читал. По факту, если ты посмотришь на реальные достаточно крупные проекты, то результат один: огромный базовый god object с методами на все случаи жизни, от которого наследуются мелкие конкретные реализации. Ну и где твои авторы книжек? Как правло, онри выдают не связанные с реальность примеры, выдуманные плюшевые сложности, которые автор с легкостью решает своим тонким и прозорливым умом. Но по факту этот автор за свою жизнь не написал больше 10 тысяч строк, однако же, учит тебя писать сложные системы.

Адепты класс-ориентированного программирования с ноги запихивают методы работы с объектами в сами объекты, и делают вид, что так понимать код стало проще

Методы обеспечивают динамическую диспетчеризацию вызова по таблице методов объекта слева. Там, где она (диспетчеризация) вам нужна — используйте. Там, где не нужна — не используйте. Всё логично. Есть задача, есть под неё инструмент

Типовая проблема с твоим подходом — это когда я абсолютно точно знаю тип значения и мне не нужна динамическая диспетчеризация.

В JS по этой причине очень часто можно увидеть строки вроде Array.prototype.map.call(value...) или чуть покороче [].map.call(value...). Второй подход к решению проблемы статической диспетчеризации, который можно часто увидеть в стандартной библиотеке CPython — это пересоздание объекта через конструктор конкретного типа, например:

def somefunc(argument):
    val = str(argument)
    ...

Это, на самом деле, и является основной целью статической типизации, то есть, внесение предсказуемости в поведение моего кода, чтобы я был уверен, что мой код будет работать так, как я его написал и оттестировал, а не так, как в него передадут аргументы. Короче говоря, изоляция областей ответственности и локальное тестирование, или еще короче — модульность. По этой причине, например, CPython является языком со слабой модульностью, хотя, казалось бы, модули в нем есть — но они там только для виду и больше похожи на динамически подгружаемые строки кода, аля os = eval(open("os.py")). Как это когда-то делалось и в JS, пока в ES2015 не ввели настоящие модули.

И нет, статическая типизация сделана не ради рефакторинга. Рефакторинг является бессмысленной затеей, которая возникла прежде всего из-за большого объема ручной работы, требуемой для рефакторинга жавы. Потому рефакторинг является недостатком языка, а не его преимуществом. Грамотно написанный проект на языке программирования вместо жавы не требует длинного автоматического рефакторинга, чаще требуя ручного вдумчивого вмешательства, где статическая типизация уже не играет серьезной роли.

Ты заметил, что классы не помогают решать эту проблему? Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом.

https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

Это абстрактное исследование в вакууме показало, что 65-93% всех вызовов методов, как правило, вызывают только один-единственный статичный метод. Попытка сделать весь язык вокруг диспетчеризации по одному аргументу значит, что язык строится вокруг 13-32% всех вызовов в программах. Причем, проблема диспетчеризации по нескольким аргументам, как правило, в таких языках не решена вообще никак, таким образом отправляя эти 3-7% вызовов методов на костыли и «паттерны программирования».

На практике в архитектуре мы имеем дело не с числами, а со всякими плагинами, виджетами, менеджерами, менеджерами менеджеров, абстракциями над объектами БД и т.п. Всему этому нужна динамическая диспетчеризация

У тебя «преждевременная диспетчеризация». В большинстве случаев она не нужна, но сложно угадать, когда пригодится. Правда, с таким же успехом тебе может понадобится диспетчеризация по нескольким аргументам — и что ты тогда делать будешь?

Это проблема невротичного ума, а не классов. Читайте книги по архитектуре кода, там все эти типовые ошибки рассматриваются, когда в класс суют не то, что к нему относится

Подразумеваешь, что я эту парашу еще не читал. По факту, если ты посмотришь на реальные достаточно крупные проекты, то результат один: огромный базовый god object с методами на все случаи жизни, от которого наследуются мелкие конкретные реализации. ну и где твои авторы книжек? Как правло, онри выдают не связанные с реальность примеры, выдуманные плюшевые сложности, которые автор с легкостью решает своим тонким и прозорливым умом. Но по факту этот автор за свою жизнь не написал больше 10 тысяч строк, однако же, учит тебя писать сложные системы.

Адепты класс-ориентированного программирования с ноги запихивают методы работы с объектами в сами объекты, и делают вид, что так понимать код стало проще

Методы обеспечивают динамическую диспетчеризацию вызова по таблице методов объекта слева. Там, где она (диспетчеризация) вам нужна — используйте. Там, где не нужна — не используйте. Всё логично. Есть задача, есть под неё инструмент

Типовая проблема с твоим подходом — это когда я абсолютно точно знаю тип значения и мне не нужна динамическая диспетчеризация.

В JS по этой причине очень часто можно увидеть строки вроде Array.prototype.map.call(value...) или чуть покороче [].map.call(value...).

Второй подход к решению проблемы статической диспетчеризации, который можно часто увидеть в стандартной библиотеке CPython — это пересоздание объекта через конструктор конкретного типа, например:

def somefunc(argument):
    val = str(argument)
    ...

Это, на самом деле, и является основной целью статической типизации, то есть, внесение предсказуемости в поведение моего кода, чтобы я был уверен, что мой код будет работать так, как я его написал и оттестировал, а не так, как в него передадут аргументы. Короче говоря, изоляция областей ответственности и локальное тестирование, или еще короче — модульность. По этой причине, например, CPython является языком со слабой модульностью, хотя, казалось бы, модули в нем есть — но они там только для виду и больше похожи на динамически подгружаемые строки кода, аля os = eval(open("os.py")). Как это когда-то делалось и в JS, пока в ES2015 не ввели настоящие модули.

И нет, статическая типизация сделана не ради рефакторинга. Рефакторинг является бессмысленной затеей, которая возникла прежде всего из-за большого объема ручной работы, требуемой для рефакторинга жавы. Потому рефакторинг является недостатком языка, а не его преимуществом. Грамотно написанный проект на языке программирования вместо жавы не требует длинного автоматического рефакторинга, чаще требуя ручного вдумчивого вмешательства, где статическая типизация уже не играет серьезной роли.

Ты заметил, что классы не помогают решать эту проблему? Динамическая диспетчеризация по одному аргументу является лишь одним, и далеко не самым популярным инструментом.

https://en.wikipedia.org/wiki/Multiple_dispatch#Use_in_practice

Это абстрактное исследование в вакууме показало, что 65-93% всех вызовов методов, как правило, вызывают только один-единственный статичный метод. Попытка сделать весь язык вокруг диспетчеризации по одному аргументу значит, что язык строится вокруг 13-32% всех вызовов в программах. Причем, проблема диспетчеризации по нескольким аргументам, как правило, в таких языках не решена вообще никак, таким образом отправляя эти 3-7% вызовов методов на костыли и «паттерны программирования».

На практике в архитектуре мы имеем дело не с числами, а со всякими плагинами, виджетами, менеджерами, менеджерами менеджеров, абстракциями над объектами БД и т.п. Всему этому нужна динамическая диспетчеризация

У тебя «преждевременная диспетчеризация». В большинстве случаев она не нужна, но сложно угадать, когда пригодится. Правда, с таким же успехом тебе может понадобится диспетчеризация по нескольким аргументам — и что ты тогда делать будешь?

Это проблема невротичного ума, а не классов. Читайте книги по архитектуре кода, там все эти типовые ошибки рассматриваются, когда в класс суют не то, что к нему относится

Подразумеваешь, что я эту парашу еще не читал. По факту, если ты посмотришь на реальные достаточно крупные проекты, то результат один: огромный базовый god object с методами на все случаи жизни, от которого наследуются мелкие конкретные реализации. ну и где твои авторы книжек? Как правло, онри выдают не связанные с реальность примеры, выдуманные плюшевые сложности, которые автор с легкостью решает своим тонким и прозорливым умом. Но по факту этот автор за свою жизнь не написал больше 10 тысяч строк, однако же, учит тебя писать сложные системы.