Обсуждение статьи «Модульный дизайн, или «что такое DIP, SRP, IoC, DI и т.п.»»

Павел, IoC (Inversion of Control) и DI (Dependency Injection) - действительно не одно и то же. IoC - это общий принцип. Он совершенно не связан с разработкой ПО, хотя получил известность именно благодаря ей. Даже в Википедии IoC назван принципом объектно-ориентированного программирования (http://en.wikipedia.org/wiki/Inversion_of_control, http://ru.wikipedia.org/wiki/Обращение_контроля).

В своей статье об IoC Мартин Фаулер привел хорошую аналогию с т.н. «голливудским принципом» – «не звоните нам, мы вам позвоним сами». Саму статью можно прочитать вот тут: http://martinfowler.com/bliki/InversionOfControl.html.

В дополнение приведу еще один пример IoC из Java, не связанный явно с DI.

Возьмем обычную сериализацию. Как Вы знаете, существует два способа реализации - использование Serializable и Externalizable. Начнем со второго.

Что происходит при обработке Externalizable? Объекту дают поток и говорят - на, родной, пишись! И объект сам пишет свои данные. И точно так же при чтении, создается пустой экземпляр, ему дается поток и говорится - на, родной, читайся. И объект сам читает свои данные.

А что происходит в случае Serializable? Объект сам ничего не делает. Он попадает в механизм, который разбирает его по косточкам, вытаскивает из него все данные и записывает в поток. И точно так же при чтении - внешний механизм читает данные из потока и прописывает их в объект. В этом случае сам объект не является активным действующим лицом - все операции производятся над ним кем-то. IoC в чистом виде.

На самом деле, если копнуть глубже - тут наблюдается сходство с DI. И в том, и в другом случаях в определенное поле объекта пишется определенное значение. Это может быть ссылка на объект, это может быть прочитанное число. Не суть принципиально, и то и другое - IoC. Просто когда мы говорим об объектах, мы не думаем о ссылках, - это ниже того уровня абстракции, на котором мы мыслим в данный момент. Скажем так, запись ссылки - это физическая реализация установки зависимости. А на более высоком уровне абстракции мы говорим о DI. То есть можно сказать, что IoC лежит в основе принципа реализации DI, но им не ограничивается.

P.S. Запятую убрал. :)

А кто сказал, что у XMLConfiguration и DBConfiguration совершенно одинаковое поведение? Вы их сначала реализуйте до конца, а потом сравните. Ничего похожего не будет.

Насчет статических функций. Я Вам советую посмотреть на классы конфигурации из Log4J. Чтобы объем оценить. Вы действительно ЭТО хотите в одну статическую функцию запихнуть? А как только начнете разбивать - в одном классе окажется куча мелких функций, одни работают со свойствами, другие с XML, третьи с аннотациями (а ведь через месяц Вам аннотации точно понадобятся, в очередном проекте!). И Вы в них мгновенно утонете.

Кроме того, статические функции противоречат принципу OCP - при необходимости добавления новой конфигурации Вам придется менять ConcreteConfiguration. А мне придется всего лишь добавить новый класс. Отдельный, ни на кого больше не влияющий.

P.S. > их логично сделать top-level функциями модуля реализации

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

P.P.S. Длина имен функций меня волнует еще меньше. Имя должно описывать функцию, а его длина второстепенна.

Это не беда. Даже если Вы начнете просто замечать такие архитектурные приемы - будет очень хорошо. А потом незаметно придет стадия, когда Вы посмотрите на код и поймете, что вот тут жесткое связывание, надо бы ввести интерфейсы.

P.S. Думаете, я до всего этого дошел сразу? Мне лет 6-7 понадобилось, чтобы только начать чувствовать такие вещи. И еще года 4 - чтобы быть способным внятно сформулировать.