МСУskyANAПредполагаешь, что евген предлагает использовать фабрики и локаторы?
Ты в упор отказываешься понимать, что речь не о реализации или неумело троллишь? :)

skyANAпропущено...
Обоснуй.
Выше обосновал. Чтож ты такой невнимательный.

skyANAМСУ, не веришь, что основной солюшин содержит порядка 400-т проектов?
Мда, ты точно читаешь непонятно чем. Я тебе про команду (проектную, понятное дело).

SeVaСуществует ряд принципов(единичная ответственность;работаем не с частностями, а с общностями;разделение интерфейсов, те говносервис на все случаи жизни,горячо пропагандируемый MCУ, должен быть разбит на части; etc), которые желательно соблюдать, иначе возможны значительные трудности при дальнейшем развитии системы или при гибких методиках, когда необходимо постоянно шить, а затем пороть.
Чудило, ты скоро захлебнешься своей феерической теорией. Какая единичная ответственность, к чему этот унылый офтоп? Ты долго будешь тупить?

SeVaDI значительно упрощает их соблюдение, делает код чище.
Помимо этого весьма желательна модульность, MEF прекрасно для этого подходит(грузим модуль, он сам себя регистрирует в системе, есть возможность реагирования на изменения).
Разницу между IoC и DI понимаешь? Чем именно DI делает код чище? Очередной отжиг кухарки

SeVaПо началу, естественно, есть трудности с этим и возможные проблемы(если разработчик четко не понимает, что скрывается за интерфейсом, то он может сделать неоптимальную реализацию), но после 2-3х проектов все делается на автомате, а там где их нет, уже чувствуются тормоза при необходимости изменений или расширении.
Тормоза в твоей головке, а не в проектах. Пипец, срочно ветеринара!

Очередная порция поноса с одними междометиями и хамством.
1. МегаСуперГовносервис - твое убогое все. Эту кучу дерьма даже трогать не буду, ковыряйся в ней сам.
Принцип разделения интерфейса на пальцах для муфлонов . Про это даже в русская вики знает и не врет.
2. Попробуй-ка объяснить разницу, уверен, будет весело. Начинай мычать, я уже пошел за попкорном.

МСУskyANADI - это одна из реализаций принципа IoC (помимо этого есть еще Factory и Service Locator).
Да ладно?


Жаль, skyANA тебя опередил. Насекомое, DI - способ реализации более общего ioc или принципа Голливуда: "Не звоните нам, мы сами позвоним".

Муся, попроси маму надеть тебе подгузник(лучше сразу три, а то при твоей производительности к вечеру опять озонировать будешь)

sdsdssdsdsВ одном из ответов прозвучало:
Следовать самому принципу инверсии IoC для уменьшения связности кода - правильно и единственно верно

И что это за принцип?

Вернее дайте ссылку где он внятно описан


Late Binding
In some application scenarios, you may have a requirement to support late binding. Late binding is useful if you require the ability to replace part of your system without recompiling. For example, your application might support multiple relational databases with a separate module for each supported database type. You can use configuration to tell the application to use a specific module at runtime. Another scenario where late binding can be useful is to enable users of the system to provide their own customization through a plug-in. Again, you can instruct the system to use a specific customization by using a configuration setting or a convention where the system scans a particular location on the file system for modules to use.



Единственно верно - слишком сильное, но
http://www.loosecouplings.com/2011/01/dependency-injection-using-di-container.html]
Spaghetti Code (No DI & no DI container used): Consider the spaghetti code metaphor for a moment. What does a metaphoric strand of spaghetti represent in software system? A spaghetti strand is a unit of code [which likely serves as a dependency for some other unit(s) of code]. So spaghetti code then is where many units of code (i.e. dependencies) are intertwined throughout the system and are difficult to separate from the whole (just list spaghetti strands on a plate of spaghetti). The system is highly coupled, and it’s difficult to change a single unit of code without changes rippling throughout the system. So why do I refer to code written without Dependency Injection as spaghetti code? Without DI, construction (and lifetime) concerns are mixed with application logic concerns. As a result, most units are likely to be highly coupled with several other units. Often the coupling is so high that nearly everything is transitively dependent on nearly everything else. DI is the antidote for highly-coupled code.

AntonariyНу и финал по ссылке достоин отдельной цитаты:
Я тут в качестве белой вороны выступлю. Исходная задача вообще решается на процедурном языке. Решение задачи вводит аж 7 новых сущностей, что, как известно, на грани возможностей человека. А если ещё сущности есть? Введение новых абстракций решает все проблемы, кроме слишком большого числа абстракций. В результате имеем код, для понимания которого требуется существенно больше усилий, чем для понимания изначального. И все для того, чтобы в каком-то гипотетическом случае переписывать меньше тестов. В качестве (не очень доказательного) примера могу привести java компонент mime4j, который с точки зрения паттернов написан идеально, но для того, чтобы воспользоваться возможностью расширения в ООП для шаблонов, приходится наследовать 5 интерфейсов IВсякоеРазное... и копипэйстить кучу кода. То есть я считаю, что пока не указан конкретный содержательный юзкейс (с тестами и сравнением вариантов), обосновывающий введение новых абстракций, подобные надстройки только загромождают и запутывают программу. На мой взгляд, это ситуация короткого одеяла -- закрывая бороду, открываешь ноги.


Все паттерны, принципы и прочие должны быть не самоцелью, а средством. Их очень много и если они не упрощают разработку и поддержку, то это означает только одно - что-то не то в консерваториях, а не в них.
Упомянутый mime4j прекрасная этому демонстрация.
Если я правильно понял(смотрел бегло), то в упомянутом mime4j нет необходимости в реализации 5 интерфейсов(есть несколько вариантов на выбор разбора), но подобные вещи лучше организовывать в виде pipeline. Подобный вариант будет значительно гибче, проще и удобней.