Я слышал так много разных определений IoC, что решил написать краткую статью об этом, чтобы упростить проблему. Вот она, может будет кому интересно: http://www.yegor256.com/2017/05/10/inversion-of-control.html

Я слышал так много разных определений IoC, что решил написать краткую статью об этом, чтобы упростить проблему. Вот она, может будет кому интересно: http://www.yegor256.com/2017/05/10/inversion-of-control.html

реквестирую сравнение со статьей фаулера

реквестирую сравнение со статьей фаулера

Я там упомянул его статью

а еще ты привел ссылку на dependency inversion от дяди боба

непонятненько

особенно не понятно почему не приведена ссылка на первоисточник где впервые засветился ioc

а что за ссылка?

сча найду

http://www.laputan.org/drc/drc.html

вроде бы оно

в целом я вангую что твоя статья не уменьшит путаницы в разнице между IoC и DIC. Меня когда просили объяснять что есть IoC я в пример приводил обработку ввода/вывода из консоли

что мол не программа дергает ввод/вывод, а некий фреймворк дергает программу

иньекция зависимостей лишь частный случай - не объект собирает свои зависимости, а зависимости волшебным образом приходят ему сверху

а DIP дяди боба это хоть и смежная штука но нет

за линк спасибо, добавлю в статью щас

короч, ближе к теме, выше хороших ссылок по IoC накидали

Я слышал так много разных определений IoC, что решил написать краткую статью об этом, чтобы упростить проблему. Вот она, может будет кому интересно: http://www.yegor256.com/2017/05/10/inversion-of-control.html

Ваще не о том получилось. Там в первом комменте тебе чувак правильно написал

PrintedBook тоже стремная штука. Ты сайд-эффекты в конструктор поместил, получается?

Я слышал так много разных определений IoC, что решил написать краткую статью об этом, чтобы упростить проблему. Вот она, может будет кому интересно: http://www.yegor256.com/2017/05/10/inversion-of-control.html

помоему вот очень хорошая статья

http://sergeyteplyakov.blogspot.ru/2014/11/di-vs-dip-vs-ioc.html

> (DIP) - это принцип проектирования, который говорит, что классы должны зависеть от высокоуровневых абстракций.

мне не нравится тут слово "высокоуровневых"

ERROR: S client not available

Почему

Потому что уровень абстракции тут не при чем

Чем бы в ООП чате не занимались, лишь бы квадрат с прямоугольником не обсуждали. Сторонники того, что нельзя наследовать квадрат от прямоугольника или наоборот и нужно наследовать его от некого Shape, чем вы думаете? Как будете потом этим пользоваться, если у квадрата incSize, а у прямоугольника incWidth, incHeight. Да, в динамически типизированном языке это почти удобно, а в статически типизированном тормозной говнокод с dynamic_cast везде где надо вызывать эти методы в общем коде. Это почти антиполиморфично. Вы там трясетесь над инвариантами. Тогда банально заведите конструктор принимающий size для квадрата и width, height для прямоугольника. В данном конкретном случае не нужны никакие методы и поэтому не будет никаких проблем с инвариантами. Ну и вполне можно завести для удобства incSize возвращающий квадрат для квадрата и прямоугольник для прямоугольника. И incWidth и incHeight возвращающий прямоугольник для квадрата и прямоугольника. То есть возвращаем новые фигуры, не меняя старые и опять же не нарушаем инварианты. Над другими фигурами поступает также.

накипело?)

Чем бы в ООП чате не занимались, лишь бы квадрат с прямоугольником не обсуждали. Сторонники того, что нельзя наследовать квадрат от прямоугольника или наоборот и нужно наследовать его от некого Shape, чем вы думаете? Как будете потом этим пользоваться, если у квадрата incSize, а у прямоугольника incWidth, incHeight. Да, в динамически типизированном языке это почти удобно, а в статически типизированном тормозной говнокод с dynamic_cast везде где надо вызывать эти методы в общем коде. Это почти антиполиморфично. Вы там трясетесь над инвариантами. Тогда банально заведите конструктор принимающий size для квадрата и width, height для прямоугольника. В данном конкретном случае не нужны никакие методы и поэтому не будет никаких проблем с инвариантами. Ну и вполне можно завести для удобства incSize возвращающий квадрат для квадрата и прямоугольник для прямоугольника. И incWidth и incHeight возвращающий прямоугольник для квадрата и прямоугольника. То есть возвращаем новые фигуры, не меняя старые и опять же не нарушаем инварианты. Над другими фигурами поступает также.

Я вот тут в свете изучения Go задумался, а может оно и не нужно вовсе это наследование?

накипело?)

Не бомбит

Я вот тут в свете изучения Go задумался, а может оно и не нужно вовсе это наследование?

а там что? функциональное или процедурное??

а там что? функциональное или процедурное??

Скорее процедурщина (но и кложуры есть), но как бы и ООП замутить можно, но это не точно)

кстати мейлру на хабре выложили видеокурс по go

Чем бы в ООП чате не занимались, лишь бы квадрат с прямоугольником не обсуждали. Сторонники того, что нельзя наследовать квадрат от прямоугольника или наоборот и нужно наследовать его от некого Shape, чем вы думаете? Как будете потом этим пользоваться, если у квадрата incSize, а у прямоугольника incWidth, incHeight. Да, в динамически типизированном языке это почти удобно, а в статически типизированном тормозной говнокод с dynamic_cast везде где надо вызывать эти методы в общем коде. Это почти антиполиморфично. Вы там трясетесь над инвариантами. Тогда банально заведите конструктор принимающий size для квадрата и width, height для прямоугольника. В данном конкретном случае не нужны никакие методы и поэтому не будет никаких проблем с инвариантами. Ну и вполне можно завести для удобства incSize возвращающий квадрат для квадрата и прямоугольник для прямоугольника. И incWidth и incHeight возвращающий прямоугольник для квадрата и прямоугольника. То есть возвращаем новые фигуры, не меняя старые и опять же не нарушаем инварианты. Над другими фигурами поступает также.

Ты долго держался