Все это круто, конечно же, но DI уместен скорее при разработке универсального фреймворка нежели частного проекта. Почему? Потому что при разработке частного проекта вы знаете и уверены в том что вам нужно для разработки, и по этому у вас не встанет вопрос перехода с одной СУБД на другую. По этому в частном проекте вы будете тратить время на реализацию реальных задач, а не на нагромождение абстракций с целью обезопасить себя на тысячу лет вперед от всех возможных случаев жизни.
С другой стороны, если вы разрабатываете открытый фрейморк, которым будут пользоваться не только вы и ваша команда (аля symfony, zf, ci, yii, etc), то вы не будете уверены в том что именно захочет сделать пользователь вашего фремворка. И тут вам придется городить огород из махровых абстракций, что бы угодить всем и вся.
Это не случай из жизни, просто хотел на скорую руку привести пример DI.
Если у вас есть пример DI лучше то милости просим, мы его с удовольствием обсудим.
У вас есть большой проект. В нем много классов моделей, которые мапятся на таблицы в базе данных. Раньше вы использовали синглтон для драйвера работы с базой данных и были счастливы. Но с увеличением нагрузки пришлось выполнить шардинг вашей базы данных. После шардинга из одной базы данных стало две. Теперь нужно два инстанса драйвера базы данных с различными настройками подключения. При этом в зависимости от модели должен возвращатся правильный инстанс базы данных. Понятное дело что синглтоном уже не обойтись. Вот тут и приходит на помощь паттерн DI.
Как это все выглядит?
Создается класс, например, DIManager. У этого класса есть метод getDbConnection( $modelName ), который в зависимости от имени модели возвращает инстанс соответствующей базы данных. Теперь все старые вызовы DBConnection::getInstance() заменяются на DIManager::getDbConnection( $modelName ). Таким образом мы ослабили зависимость модели от базы данных и теперь спокойно можем контролировать коннекшн к бд для любой модели в одном месте. Профит!
П.С.: Хрестоматийный пример IoC на PHP пока не придумал, но ворох интерфейсов и набор магических заклинаний мне кажутся избыточными и монструозными.
П.С.С.: Нельзя использовать паттерны только ради того что бы они были. Это ошибки неопытных программистов.
Ну например, можно представить сколько будет стоить проведение данного исследования (плюс возможно разработка алгоритма предсказания) внутренними силами/ресурсами Яндекса. Я думаю что расходы будут гораздо большими нежели $5000, следовательно призовые у конкурса не велики. А если сравнивать их с зарплатой программиста, работающего не в Москве/Питере/Киеве/Минске, то призовые будут велики.
Я тоже, в бытность дотнетчика, на себе тельняшку рвал и доказывал своему другу (php-ку), что строгая типизация это наше все, и что с ней жить проще, удобней и спокойней.
Но если бы у вас был опыт в обоих сверах, и в .net и в php, то вы могли бы объективно сравнивать динамическую со статической типизацией. А так как у вас опыт только в дотнете то ваше мнение субъективно ;)
Это как раз не минус а плюс языку. Тот же .net с каждым релизом становится все более лояльнее к динамической типизации (var, dynamic).
Тут дело не вкуса а опыта. У меня, например, вообще не возникает никаких проблем вызванных неправильным написанием функции или переменной. Я просто проверяю перед тем как коммитить ;)
> Ruby был задуман в 1993-м году японцем Юкихиро Мацумото, стремившимся создать язык, вобравший из других языков самые лучше подходы, облегчающие труд программиста.
HTML version timeline
November 24, 1995
HTML 2.0 was published as IETF RFC 1866.
С другой стороны, если вы разрабатываете открытый фрейморк, которым будут пользоваться не только вы и ваша команда (аля symfony, zf, ci, yii, etc), то вы не будете уверены в том что именно захочет сделать пользователь вашего фремворка. И тут вам придется городить огород из махровых абстракций, что бы угодить всем и вся.
Если у вас есть пример DI лучше то милости просим, мы его с удовольствием обсудим.
У вас есть большой проект. В нем много классов моделей, которые мапятся на таблицы в базе данных. Раньше вы использовали синглтон для драйвера работы с базой данных и были счастливы. Но с увеличением нагрузки пришлось выполнить шардинг вашей базы данных. После шардинга из одной базы данных стало две. Теперь нужно два инстанса драйвера базы данных с различными настройками подключения. При этом в зависимости от модели должен возвращатся правильный инстанс базы данных. Понятное дело что синглтоном уже не обойтись. Вот тут и приходит на помощь паттерн DI.
Как это все выглядит?
Создается класс, например, DIManager. У этого класса есть метод getDbConnection( $modelName ), который в зависимости от имени модели возвращает инстанс соответствующей базы данных. Теперь все старые вызовы DBConnection::getInstance() заменяются на DIManager::getDbConnection( $modelName ). Таким образом мы ослабили зависимость модели от базы данных и теперь спокойно можем контролировать коннекшн к бд для любой модели в одном месте. Профит!
П.С.: Хрестоматийный пример IoC на PHP пока не придумал, но ворох интерфейсов и набор магических заклинаний мне кажутся избыточными и монструозными.
П.С.С.: Нельзя использовать паттерны только ради того что бы они были. Это ошибки неопытных программистов.
Ну или опять таки как подсказали в этом комментарии habrahabr.ru/blogs/algorithm/132058/#comment_4384968 существуют конкурсы и по прибыльней.
Смотря с чем сравнивать.
Но если бы у вас был опыт в обоих сверах, и в .net и в php, то вы могли бы объективно сравнивать динамическую со статической типизацией. А так как у вас опыт только в дотнете то ваше мнение субъективно ;)
> Потому что проверять перед коммитом надо меньше
Ну вы же не с закрытыми глазами коммитете, все равно проверяете ;)
Тут дело не вкуса а опыта. У меня, например, вообще не возникает никаких проблем вызванных неправильным написанием функции или переменной. Я просто проверяю перед тем как коммитить ;)
HTML version timeline
November 24, 1995
HTML 2.0 was published as IETF RFC 1866.