и его стандартную библиотеку например)

ну логично, надо головой думать

если у тебя там два контроллера и одна моделька - можно взять какой-нить микрофреймворк (например silex, если мы про php) и сделать все в одном файле

и будет ок

и счастье и пони на радуге

но когда система начинает усложняться, фреймворк начинает диктовать свои условия и мешать

вносит тот самый design damage

https://www.youtube.com/watch?v=tg5RFeSfBM4

вот классика

@fes0r расскажи про свое видение модулей)

Меня вопрос ваще капец как волнует (

Ну точнее, где живет клей для модулей

в модуле)

не сказать что у меня "ясное виденье" модуля)

ну то есть у тебя есть модуль и он что-то делает

он может внутри использовать другие модули

и вся система - модуль

ну то есть - Д - декомпозиция

где лежат модули и кому принадлежат - coheasion

Ну, если взять пайтон/esm, то используя модули мы будем выстраивать пирамидки

пирамидки?

Главный модуль импортит модули верхнего уровня, они модули ниже

И т.д.

Пирамидка

нуууу.... тип того

В то время как хочется модули верхнего уровня абстрагировать от нижнего

И сделать их зависимыми от абстракций

эм.... а у тебя это не достигается?

ну то есть ты говоришь например в питоне - "хочу модуль foo"

и ты знаешь что этот модуль предоставляет тебе определенный интерфейс по работе с оным

а реализация - скрыта

ну и ты можешь переопределить откуда берется модуль

по сути ты получаешь ровно то же самое что и в случае с IoC

Ну примерно также, как если я говорю, что завишу от конкретного класса)

просто чуть-чуть по другому и менее явно

Как бы скрыта и я взаимодейтсвую только с публичным интерфейсои

Ну примерно также, как если я говорю, что завишу от конкретного класса)

не совсем. Ты зависишь от модуля. у модуля может быть много реализаций

Это как?

если они соблюдают контракт. Сложность именно с последним, контракт выходит неявным

Это как?

import {foo} from 'fooModule';

И?

у тебя модуль fooModule должен иметь функцию foo

которая что-то делает

Да

ну.... ты можешь подменить реализацию

import {foo} from 'barModule';

но... хотя

import {foo} from 'barModule';

не не

Также как в классе метод

Могу заменить да)

почему?

нельзя менять код)

а

но ты можешь переопределить откуда брать модуль fooModule

и подсовывать вместо него fooModule

Ага, также как могу переопределить загрузчик классов

во всяком случае в питоне

Ага, также как могу переопределить загрузчик классов

только если ты не завязан на типы

только если ты не завязан на типы

?

то тогда да и в целом я тут подумал что это не дает late binding

ну то есть в рантайме ты уже не так легко можешь зависимости подменить... хотя

Ну понимаешь мою проблему?)

ну в целом смотри

В пайтоне активно юзают инъекцию в конструктор

тут идея насколько я понимаю - та же что и с IoC но вывернута наизнанку

В пайтоне активно юзают инъекцию в конструктор

есть такое, но еще там часто не юзают классы

ну мол.... с модулями - ты не паришься о зависимостях модуля. Тот сам разрулит. Как через сервис локатор

Вообще

ERROR: S client not available

и у тебя есть возможность переопределить сервис локатор для модуля

что бы подсовывать ему другие зависимости

В чем профиты позднего связывания

В рантайме можно определять зависимости и менять флоу программы

Можно модуль выдрать из системы простым cp

В чем профиты позднего связывания

возможность подменить реализацию в рантайме. Ты ж вспомни - это было в smalltalk. Там у тебя объекты имеют разный цикл жизни и ты можешь как бы... перезапустить только часть системы, подменить реализацию в рантайме

это как распределенная система акторов

возможность подменить реализацию в рантайме. Ты ж вспомни - это было в smalltalk. Там у тебя объекты имеют разный цикл жизни и ты можешь как бы... перезапустить только часть системы, подменить реализацию в рантайме

Так да

и late binding обеспечивал возможность подменять объекты и они даже не замечали что общаются уже с другим

Ну и тут еще

это как перезапустить тред в erlang

Захотелось в разных местах разные реализации

Или даж в рамках одного модуля

Тут мы автоматически проиграли

Но списываем на редкость кейса

нуууу не то что бы

вообще интересная тема

Пирамидки это из паскаля, late binding это смолток и лисп

ну тип того... но вообще надо сча погуглить

в целом... надо как-то углубиться в историю

https://en.wikipedia.org/wiki/Modula-2

ну модула уже после паскаля была

ну да

но там модули более явно сделаны

сча гуглю почему Вирт замутил так

и почему начал развивать идею

или вот еще накину

Си

там "интерфейс" модуля - заголовочный файл и есть файл с реализацией.

и ты можешь подменять реализацию

на этапе компиляции

импортируешь ты только заголовочные файлы как интерфейсы