Разбор ООП с Delphinum

# Delphinum (20.01.2017 / 19:19)
AlkatraZ, это холиварная тема, но мир веба движется в сторону интерфейсов. То есть сначала интерфейс, который описывает что умеет класс, а затем уже его реализация (или несколько полиморфных реализац

Если нет абстракции и не подразумеваются разные реализации интерфейса, то тогда зачем плодить лишние файлы?

AlkatraZ, дело в том, что абстракция есть всегда. Конечно если не предполагается (сейчас) полиморфная реализация некоторой абстракции, то можно и не использовать интерфейсы, но если в будущем такая потребность появится, то инвертировать зависимость будет сложнее, чем сделать это сразу.

Да и не сложно ведь писать эти самые интерфейсы )

P.S. Сам далеко не всегда пишу их, всегда ориентируюсь на конкретный случай

Сильно зависит от конкретной реализации...

Если используешь контейнер-сервисменеджер, типа нового Зендовского, там таки да, есть смысл ДЛЯ ВСЕХ сервисов, что гонятся через контейнер написать интерфейсы. Фактически они определяют твой внутренний API и конечному пейсателю модулей будет пофиг, а на чем там конкретно написано ядро: Зенд, Симфония, или Ларавель или хз что еще...

Главное - ты запрашиваешь из контейнера интерфейс, а он уже выдаст тебе его реализацию.

Я вот в Моби так и планирую сделать.
Тем более, что там будет семантическое версионирование и по интерфейсам легко отслеживать (для кордера, писателя модулей), что изменилось и нафига апнулась мажорная версия.

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

Конечно для проектов типа dcms проблематично будет использовать такой подход )

в 3енде вообще без интерфейсов ни куда, что не переделать, везде надо следовать интерфейсу

Koenig, ну можно себе в ногу выстрелить, если не следовать заложенной семантике )

# Delphinum (20.01.2017 / 19:44)
AlkatraZ, ну вот примерно такая же логика и при разборе всего проекта. Другими словами - если можно написать интерфейс, если получилось выделить абстракцию для этого, лучше писать чем не писать, мень

Да, тут согласен.
Интерфейсы - это твой внутренний API.
---
Просто вот думал, куда их пихать?
Теоретически, надо было бы создать отдельную папку /vendor_name/api/... ну короче в свой неймспейс впихнуть раздел "api" где все и собрать. Ведь если следовать логике, ХЗ какими пакетами и наворотами ты будешь реализовывать эти интерфейсы? ты еще этого не знаешь, или же потом может поменяться.

Посему есть смысл API интерфейсы выделять в отдельный пакет со своим неймспецсом.
И потом писать к нему документацию, не задумываясь о реализации, она вторична.

AlkatraZ, варианта два:
1. Ты либо пишешь интерфейсы по аналогии с PSR:

namespace YourPackage;

interface YourInterface{
  ...
}

а другие пакеты их реализуют
2. Либо ты засовываешь интерфейсы в пакет с его же реализацией:

Router/
  RouterInterface.php - интерфейс
  Router.php - реализация
  Rule/
    RouteRuleInterface.php - интерфейс
    RegextRule.php - реализация
    ListeralRule.php - реализация

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

Я имею в виду отдельный пакет Api, который содержит только интерфейсы, без реализаций.
Далее, уже через конфиг контейнера ты сопоставляешь интерфейс => реализация.
Это системный API.
---
К примеру, если пишем движок - это API движка.