я думаю это скорее будет реализация иос

Да. Но я имел ввиду когда фабрика внутри диай контейнера и ты как зависимостб передаешь метод возвращающий обьект нужногл типа

IoC это не интерфейс

короче смотри примитивный пример

есть у логика работа с бд

и бизнес логика

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

это ты кому обьясняешь?)

но иногда очень хочется

артуру

я тоже слушаю

ioc это как бы принцип который говорит что бизнес логика должна лежать на уровне бизнес логики

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

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

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

а еще и кучей других способов и подходов

ioc это как бы принцип который говорит что бизнес логика должна лежать на уровне бизнес логики

Ты уверен что ты про ioc а не про di principal?

солидарен

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

и как вызывается

другой пример оопшный

все понимают что такое агрегация7

да

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

че то ты как то издалека решил подобраться к обьяснению иос))

это как бы dip

но когда объект создан поток управления объектом находится в том месте где создали этот объект используя di

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

с другой стороны есть фреймворк он используя di запрашивает объекты

вы реализуете эти объекты но код как бы одинаквый обрабатывается и потоком управления вы уже не рулите

пример в паттерн наблюдатель

ну вот, это понятно

спасибо

получается что ioc это dip, di. полиморфизм на интерфейсах и тд

связка разная может быть

как то так но это очень грубо

лучше погуглите более авторитеные источники

https://martinfowler.com/bliki/InversionOfControl.html

более подробно и понятно а не как я через одно место

ну и вот хороший краткий ответ https://toster.ru/q/287877

че то ты как то издалека решил подобраться к обьяснению иос))

можно еще зайти с типо патернов структрные и поведенческие)

и от туда плясать

сейчас коняш придет и скажет все не так

ну вот опять: DI - это частный случай IoC, с IoC вам нужно самим вызвать/доставать нужные "компоненты", когда DI сам их вам поставляет, например в качестве параметров в ф-ии.

никто не мешает юзать di в ioc

суть ioc не в создание объекта

а в его поведение после создания

почему DI считаеют частным случаем IoC

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

?

а в другом не ты

почему DI считаеют частным случаем IoC

второй ответ на тостере хуйня

читай только первый ответ

или читай фаулера

про IoC и DIP я понял

я не пойму почему DI считают частным случаем IoC? неужели это настолько распространенное заблуждение?

или это я заблуждаюсь, что так перестал считать?

имхо распространенное заблуждение

блин, спасибо огромное)

теперь буду унижать людей рассказывая им про di ioc dip)

а где тип возвращаемого значения?

ну видишь там function в php скорее всего функции первого класса, как в js, а классы эмулируются через мапы в которых ключ строка, а значение функция.

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

ну само собой с оговорками)

...то это и есть тестируемость / модульность / разделение ответственности / whatever. Код при этом вполне себе может быть не в парадигме ООП.

функциональный код == не тестируемый код

опять неразбериха)

функциональный код == не тестируемый код

лол

функциональный код или функциональное программирование?)

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

которое тестировать просто замечательно

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

это была отсылка к этому

это была отсылка к этому

по итогу я правильно понял?

Нет

Нет

получается не тестируемый код это хорошо спроектированный ооп код)))

Тесты никак не связаны с парадигмой

Троль

Тесты никак не связаны с парадигмой

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

спорное заявление

Если код написан - он тестируется

Если код написан - он тестируется

Совсем нет

Если тесты есть - код можно писать

Совсем нет

Чего у тебя нет?

Странные у вас разговоры ? Код может либо подлежать тестированию, либо не подлежать. Если подлежит, то это хороший код и тесты там будут адекватные, если не подлежит - код нуждается в совершенствовании, без которых покрывать его тестами будет проблематично, но возможно. Парадигма может накладывать лишь свои особенности в покрытии тестами, но на уровне тестируемости кода не сказывается

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

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

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

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

Когда требования меняются - это нормально

Я про другое. Все проверяют свой код на работоспособность. Но не все сохраняют проверки как автотесты.