[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Обсуждения DI
Страницы: 1, 2, 3, 4
bestxp
Servise - WAT Service

во вторых я считаю что в контейнере должно быть 2 состояния
1 когда сервисы конфигурируются
2 когда их уже нельзя изменить

притом на 1ом этапе мы можем менять классы
и вызов в идеале получается отложенным до момента 2

и уже после будет вызыван класс который был законфигурирован
twin
Цитата (bestxp @ 20.10.2015 - 09:18)
Servise - WAT Service

Уже подсказали, исправил на гитхабе. Сейчас здесь исправлю.

Цитата (bestxp @ 20.10.2015 - 09:18)
во вторых я считаю что в контейнере должно быть 2 состояния
1 когда сервисы конфигурируются
2 когда их уже нельзя изменить

притом на 1ом этапе мы можем менять классы
и вызов в идеале получается отложенным до момента 2

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

Не понял логики, если чесно. Почему нельзя изменить?

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
bestxp
а зачем менять ?
ты сконфигурировал и все

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

если у тебя возвращаеться по сервису app.security = класс \ABC\Security то он после запуска приложения уже не должен меняться, а вот во время конфигурации пожайлуста меняй

Если кто-то может менять конфигурацию во время исполнения и поменяв например \Some\Security то приложение вообще развалиться и станет уязвимым

например после запуска прилоежния у тебя есть событие например onkernelRequest
в котором у тебя инициализируется твоя система безопасности и проверяет какие-то данные и сохраняет в себе в памяти ( например какой-то временной токен у платежной системы )

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

это есть сравнить так

во время езды ты в принципе можешь снять коробку передач у машины, но не факт что это безопасно и тебя не прибьет, но переключать состояние их ты вполне себе можешь ( переключать скорость и тормозить )

а вся твоя конфигурация по сути определена при сборке и покупке, и замена чего-то это уже другой разговор, так как пока ты едешь в машине ты ни двигатель ни аккумулятор менять не будешь, не сможешь да и еще опасно
chee
А на мой вопрос будет ответ? Ну с подменой зависимости?

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
twin
Цитата (chee @ 20.10.2015 - 13:27)
А на мой вопрос будет ответ? Ну с подменой зависимости?

Ой, не заметил вопроса.
Цитата (chee @ 20.10.2015 - 07:19)
WAT? Клиенты могут удалять из контейнера объекты?
А почему нет? В PHP есть unset, unlink, free_result, close в конце концов. Чем сервис лучше? Если объект использован полностью, а скрипту еще пахать и пахать, можно не хранить его в памяти, а просто удалить.
Цитата (chee @ 20.10.2015 - 07:19)

Вопрос: Что будет если в определенном модуле системы, который уже работает с зависимостью MyClass из контейнера, я захочу ничего не меняя подменить зависимость на такую же по интерфейсу, но при этом ничего не меняя в самом модуле и что бы для всех остальных компонентов системы MyClass был прежним?
Ничего не понял. Что поменять ничего не меняя? Конкретнее можно пример. Я чето такой ситуации не могу себе представить.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
twin
bestxp
Вобщем то логично. Нужно сделать клонирование или прототипа. Я подумаю, спс за наводку.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image
chee
Цитата (twin @ 20.10.2015 - 17:45)
А почему нет? В PHP есть unset, unlink, free_result, close в конце концов. Чем сервис лучше? Если объект использован полностью, а скрипту еще пахать и пахать, можно не хранить его в памяти, а просто удалить.

ну bestxp написал, что из машины которая едет, опасно менять коробку передач. Но этот вопрос я снимаю, так как подомный косяк у меня в системе тоже есть, и я помню причину его создания.

Цитата (twin @ 20.10.2015 - 17:45)
Ничего не понял. Что поменять ничего не меняя? Конкретнее можно пример. Я чето такой ситуации не могу себе представить.

Вот тут есть пример кода, http://cheevauva.blogspot.ru/2015/02/blog-post_88.html с внедрением зависимостей. Смысл в том, что я описываю на каждый компонент его зависимости, для нескольких компонентов может быть одна общая зависимость, но при этом у меня существует возможность для конкретного компонента эту общую зависимость подменить на другую, при этом другие компоненты и их зависимости это не затронет.

В коде это так

$injections = array(
'Object1' => array(
'object2' => 'Object2',
),

'Object2' => array(
'object1' => 'Object1',
'object2' => 'Object2',
),

'Object3' => array(
'container' => 'DIContainer',
)
);



Я могу легко подменить зависимость object2 в Object2

$injections = array(
'Object1' => array(
'object2' => 'Object2',
),

'Object2' => array(
'object1' => 'Object1',
'object2' => 'Object3',
),

'Object3' => array(
'container' => 'DIContainer',
)
);


При этом в Object1 зависимость object2 все равно будет Object2, а не Object3.

Учитывая эти разъяснения жду ответа на вопрос выше.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.