ух как я озадачил))) esc клавиша)

кого озадачил?

зомбаки попёрли

зомбаки попёрли

ну чё ты

коняш, скажи ему, что я не зомбяк

целый зоопарк тут

Ребят всем привет , можете посоветовать хорошую книгу по алгоритмам желательно что бы практика там тоже была

классика не меняется: CLRS и Кнут

Кормен

Да, 100% начинать надо с clrs

До кормена можно ещё Кормен: "введение в алгоритмы"

Не, это лишнее

Для разгона

После кормена советую "The Art of Multiprocessor Programming".

200 страниц всего

+ Algorithms. 4th edition

С Принстонским курсом на курское параллельно

спасибо

и SICP

sicp обязателен к прочтению, это да. Но к алгоритмам я бы не относил

Хотя, там попутно всякие неподвижные точки всплывают

https://gbracha.blogspot.com.by/2009/06/ban-on-imports.html статья вроде и ниче, но я как-то не могу сообразить, что предлагает автор. Мол вместо самих нужных зависимостей передавать фабрики(если например классы это first class cit, то можно передавать сами классы и делать с единым интерфейсом конструктора), но чет профита я не понял

если ipod из примера требует от нас еще какой-нибудь драйвер для icloud или itunes, то получится уже не так красиво, вместо: SoundSystem(Ipod) что-то вроде SoundSystem((s) => Ipod(iTunes, s))

Не волнуйся

он просто поехавший

ну он говорит, что dep injection это костыль, но что взамен предлагает сложно понять

конечно di это костыль

конечно di костыль, фабрики наше все

где надоели фабрики делаем строителей (Builder)

На уровне классов di костыль, потому что есть generic-и и чаще всего надежнее и проще через них. А на уровне модулей... зависит от применения. Если для тестирования, то костыль, ибо лучше подменить импорты, где это возможно, конечно. А если не для тестирования, то я даже хз зачем DI для модулей может понадобится

дискасс

На уровне классов di костыль, потому что есть generic-и и чаще всего надежнее и проще через них. А на уровне модулей... зависит от применения. Если для тестирования, то костыль, ибо лучше подменить импорты, где это возможно, конечно. А если не для тестирования, то я даже хз зачем DI для модулей может понадобится

про уровень классов что ты имеешь ввиду?

di через генерик?

Ну, сейчас мы говорим о чём-то сильно абстрактном, просто портив воздух

в идеале di используется для реализации DIP в основном

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

опять же это все про сверху-вниз, что я в прошлый раз писал.

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

а потом когда реализовали интерфейсы, склеили это все в main-рутине или каком-нибудь конфиге фреймворка

А зачем?

конфига рутины или фреймворка это di

Если тебе это на этапе разработки, то сделай пустые модули и всё

ну модуль будет содержать интерфейс

он не будет пустым

а реализация будет еще непонятно какая

Будет, но в каждом интерфейсы будет notimplemented!()

может я там захочу в гугл диск писать

И что?

в интерфейсе вообще не будет реализаций ж

Можно конкретный пример какой-то?

Я не понимаю как от интерфейса внезапно приходите к di

WriterInterface{save (FileInterface file) }

и таких объектов реализующих WriterInterface может быть много

Google, DropBox, Amazon, etc

WriterInterface{save (FileInterface file) }

Отлично. Дальше где нужно у тебя class Compressor<W: WriterInterface> {}

т.е. дженерики о чём и говорил

так аргументы для создания google

и дробокса и амазона

авторизация разная может

DI очень хорош, когда работаешь с легаси. Новые вещи пишешь в di, а внутри легаси юзаешь di как сервислокатор.

быть, а может быть и не разной

ERROR: S client not available

конструкторы везде разные

И все довольны

Отлично. Дальше где нужно у тебя class Compressor<W: WriterInterface> {}

конструкторы WriteInterface могут отличатся

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

А кто тебе сказал, что создаётся он внутри?

Он не обязан создаваться внутри

А может и создаваться, если унифицировано

так эта лапша и будет

где то

Т.е. зависит от задачи, о чём я и говорю

без разницы где

Какая лапша, что ты несёшь

тебе надо объект реализующий WriterInterface

Можно конкретный пример какой-то?

https://gist.github.com/mkusher/b078bc5d23add860c3deeb4593dc50e5

на одном проекте это Google

Catalog и Notificator - интерфейсы

на другом DropBox

на третем просто файлы в папку сохранять

пока что непонятно как лучше рассылать уведомления и кто это вообще будет делать, может быть это сделает сторонние ребята на аутсорсе, может мы чуть позже

и параметры создания Google, DropBox и тд в конструкторе разные

с каталогом тож неясно на этом этапе

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

и параметры создания Google, DropBox и тд в конструкторе разные

Я тебе уже ответил на это, я не понимаю, почему ты продолжаешь игнорировать мои сообщения

Я тебе уже ответил на это, я не понимаю, почему ты продолжаешь игнорировать мои сообщения

ок

ты прав )

Catalog и Notificator - интерфейсы

Где будет вызываться твой addToCatalog?

Отлично. Дальше где нужно у тебя class Compressor<W: WriterInterface> {}

так и что?

Почему бы не специфицировать тот класс, который бы использовать addToCatalog?

Где будет вызываться твой addToCatalog?

фреймворком например или в меин-рутине вначале все заинъектится, а потом прокинется куда-то

так и что?

он взял абстракцию и смешал с классом ))