Вопрос по ООП синтаксис

[MiksIr]

У меня на работе проект на laravel, но делался с претензиями на лучшие практики, а на реальной практике подтверждает "Благими намерениями вымощена дорога в ад". Получилось настолько ужасно, что даже попытка двухнедельного рефакторинга пошла проекту скорее во вред, нежели сделала лучше.

Может, что-то в консерватории подправить?

 

[Absinthe]

А у конкретного объекта (внезапно, ООП вообще имеет дело с конкретными объектами) может не быть типа (класса) или интерфейса, зато может быть какой-то сервис? Прикольненько.

Гляжу в книгу - вижу фигу!

Объясните мне о чем этот товарищ говорит, что за новое слово в программировании не на интерфейсах, а на сервисах?

Ну если прочитаешь внимательно, что я написал, не меняя порядок слов, то можешь и без помощи разобраться.

 

[MiksIr]

Я просто вам открою глаза. Когда мы в коде требуем какой-то интерфейс (@var DoctrinaInterface) - мы тоже требуем объект, инстанс класса реализующего интерфейс. Т.е вашими словами - требуем сервис.

И наоборот - когда мы требуем некий сервис - мы требуем объект вполне определенного интерфейса - иначе вы просто работать с ним не сможете.

Я не знаю, откуда у вас эта каша про сервисы, может вас смущает, что сервис - это некое имя никак не определенное синтаксическими конструкциями кода, а интерфейс - это значит где-то есть interface xxx {}? Ну тогда вы не понимаете, что такое интерфейс.

И уж точно отличие SL от DI не состоит в том, что в первом случае объект зависит от сервисов, а во втором - от классов и интерфейсов.

Аминь.

 

[Absinthe]

Я не знаю, откуда у вас эта каша про сервисы, может вас смущает

Я просто вам открою глаза.

Давай сначала свои откроешь?
Ты меня не понял, судя по твоим ответам,и начинаешь спорить и хамить.
Предлагаю отойти немного назад и начать с этого:

Когда мы в коде требуем какой-то интерфейс (@var DoctrinaInterface) - мы тоже требуем объект, инстанс класса реализующего интерфейс. Т.е вашими словами - требуем сервис.

Такой код будет работать в том случае, когда есть автоматическое разрешение зависимостей по типам (называется autowire).
В Symfony, например, такого по умолчанию нет. И надо создавать описание сервиса, давать ему некоторый идентификатор, и передавать этот идентификатор для обозначения зависимости.
Вот этот объект, описанный идентификатором, и является сервисом. Он, конечно, имеет какие-то типы. Но сервис - это именно объект, а не тип.

 

[Вурдалак]

ну, ну. а я буду страдать со свои хоткеем в IDE на find usage и лишу себя долгого эротического путешествия по иерархиям конфигов и проведу это время за скучным распитием пива.

Ты можешь использовать обычный массив с ::class в конфиге и find usages будет работать.

 

[MiksIr]

Такой код будет работать в том случае, когда есть автоматическое разрешение зависимостей по типам (называется autowire).
В Symfony, например, такого по умолчанию нет. И надо создавать описание сервиса, давать ему некоторый идентификатор, и передавать этот идентификатор для обозначения зависимости.
Вот этот объект, описанный идентификатором, и является сервисом. Он, конечно, имеет какие-то типы. Но сервис - это именно объект, а не тип.

Т.е. в Симфони - сервис-локатор?

 

[Absinthe]

Т.е. в Симфони - сервис-локатор?

DI без автосвязывания.
Все зависимости надо прописывать явно, объявляя все идентификаторы.

 

[MiksIr]

Резюмируя по вашим постам.
Если в коде класса зависимость описана аннотацией с указанием "сервиса" - это SL.
Если в коде класса аннотация с указанием интерфейса - это DI.
Если в коде класса ничего нет, а зависимость описана где-то в конфиге посредством интерфейсов - это DI.
Если в коде класса ничего нет, а зависимость описана где-то в конфиге посредством "сервисов" - это тоже DI.
Все так, теперь правильно понял?

 

[Absinthe]

Если в коде класса аннотация с указанием интерфейса - это DI.

Это как?

 

[MiksIr]

Это как?

/** @var DatabaseInterface */
public $database

или

__construct(DatabaseInterface $database)

 

[Absinthe]

/** @var DatabaseInterface */
public $database

или

__construct(DatabaseInterface $database)

Да, такая конструкция может быть использована для autowired DI. Тут нет указания имен сервисов.
Естественно, при использовании нескольких сервисов одного типа придется где-то конфигурировать зависимости явно, как тут: http://laravel.com/docs/5.0/container#contextual-binding.

 

[grigori]

MiksIr, Absinthe, в этом разделе надо писать спокойней и без личного, хотите ругаться - идите в мусорку

 

[MiksIr]

Ладно, я понял, что мне дальше лень.
Почитай, просто, что такое сервис-локатор. Паттерн есть такой.

 

[grigori]

про конкатенацию имен классов - в yii спасает то, что она есть только в контроллерах, и эти классы никогда не вызываются из кода приложения,
а оператор ::class, к сожалению, появился совсем недавно

 

[Absinthe]

Почитай, просто, что такое сервис-локатор. Паттерн есть такой.

Когда я писал SL, то я как раз имел ввиду этот паттерн.

 

[MiksIr]

MiksIr, Absinthe, в этом разделе надо писать спокойней и без личного, хотите ругаться - идите в мусорку

Так перенесите. Тем более многим постам там и место, что бы не смущать людей, которые придут за информацией.

 

[Absinthe]

про конкатенацию имен классов - в yii спасает то, что она есть только в контроллерах, и эти классы никогда не вызываются из кода приложения

А методов?

 

[grigori]

В DIC все зависимости расписаны в конфиге или группе конфигов (разбросанных по приложению, но с определенной логикой).
Таким образом, если мы вдруг решили выкинуть или заменить какой-либо сервис, мы можем быстро пробежаться глазами по конфигам и узнать, где этот сервис используется, и что можно случайно сломать.
Вместо поисков в 100500 файлов SL контейнеров и вызовов этого сервиса.

Это один из use case, но для меня - наиважнейший. Можно пробежаться глазами по конфигу и у тебя вся архитектура перед глазами.
В том же Ларавел, зависимости могут включатся не напрямую через конфиг, а через магию и рефлексию по тайпхинтингу... и это жесть имхо.

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

 

[grigori]

А методов?

если ты про __get/__set магию - вообще не имеет отношения к этой теме, это лишь сахар, никакого отношения к сервисам, DI и вообще ни на что не влияет

пытаюсь вспомнить где еще, не могу

 

[Absinthe]

если ты про __get/__set магию - вообще не имеет отношения к этой теме, это лишь сахар, никакого отношения к сервисам, DI и вообще ни на что не влияет

пытаюсь вспомнить где еще, не могу

Даже конкретней про такую магию: посмотри как в главном классе CComponent они сделаны. IDE такое найти не может.