Разбор ООП с Delphinum

Delphinum, тогда получится это интерфейс конкретного модуля, а не всей системы в целом, про второй вариант, я так понял Олег про апи говорил, как про масштабное, а не локальное

AlkatraZ, возможно я плохо объяснил, но вот пример такого пакета, о котором ты говоришь:
https://packagist.org/packages ... ssage
чистая семантика, строго стандартизирующая возможности реализации.

На уровне контейнера ты уже должен будешь выбрать конкретную реализацию из множества возможных и через interface => class сконфигурировать контейнер.

# Koenig (20.01.2017 / 20:58)
Delphinum, тогда получится это интерфейс конкретного модуля, а не всей системы в целом, про второй вариант, я так понял Олег про апи говорил, как про масштабное, а не локальное

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

# Delphinum (20.01.2017 / 21:02)
AlkatraZ, возможно я плохо объяснил, но вот пример такого пакета, о котором ты говоришь:
https://packagist.org/packages ... ssage
чистая семантика, строго стандартизирующая возможности реали

одни интерфейсы гг

# Delphinum (20.01.2017 / 20:51)
AlkatraZ, варианта два:
1. Ты либо пишешь интерфейсы по аналогии с PSR...
2. Либо ты засовываешь интерфейсы в пакет с его же реализацией...

Вариант 2 отметаем сразу же как раз из-за того, что тянется куча лишнего.
Вариант 1 отметаем потому что ты охренеешь поддерживать целую кучу пакетов. Вы же про движок говорите.
Поэтому вариант 3: один пакет со всеми возможными интерфейсами как в laravel c его illuminate/contracts

# Koenig (20.01.2017 / 21:07)
одни интерфейсы гг

Практически все Interop или многие PSR стандарты - это чистые интерфейсы, без реализации.

# reaper (20.01.2017 / 21:08)
Поэтому вариант 3: один пакет со всеми возможными интерфейсами как в laravel c его illuminate/contracts

Ну о чем я и писал выше

# AlkatraZ (20.01.2017 / 21:09)
Ну о чем я и писал выше

Ну я попытался перефразировать, внести ясность так сказать.

# reaper (20.01.2017 / 21:08)
Вариант 2 отметаем сразу же как раз из-за того, что тянется куча лишнего.
Вариант 1 отметаем потому что ты охренеешь поддерживать целую кучу пакетов. Вы же про движок говорите.
Поэтому вариант 3: од

На деле вариант 2 более распространен, потому что ты не издаешь стандарты чтобы пользовать вариант 1, ты пишешь готовые решения, которыми будут пользоваться. Другими словами если ты будешь создавать пакеты с чистыми интерфейсами, нах они кому будут нужны? )

А зачем в варианте 1 поддерживать кучу пакетов? Твое дело поддерживать качественную семантику своего пакета, а разработчики реализаций уже будут заботиться о своих пакетах

Нее, пакет со всеми возможными интерфейсами рано или поздно столкнется с проблемой сборки движка из кусков. Может мне нравится PSR7 но не нравится PSR11, зачем мне тянуть все виды PSR в проект, когда я могу выбрать.

На деле там не очень сложно, да репозиториев плодиться ворох, но что поделать )

# Delphinum (20.01.2017 / 21:11)
На деле вариант 2 более распространен, потому что ты не издаешь стандарты чтобы пользовать вариант 1, ты пишешь готовые решения, которыми будут пользоваться. Другими словами если ты будешь создавать п

Похоже что у нас разное представление о пакетах. Чёт даже лень разбираться. Лучше просто почитаю