Использование интерфейсов в пользовательской среде OO PHP

Ответ 1

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

Скажем, мы имеем дело с уровнем абстракции базы данных. У вас будет интерфейс iDatabase и интерфейс iDatabaseDriver. Предположим, что структура вашей папки (и класса) выглядит следующим образом:

/classes/database/idatabase.php
/classes/database/database.php
/classes/database/drivers/mysql/databasedrivermysql.php
/classes/database/drivers/postgres/databasedriverpostgres.php

Теперь есть 2 логических места для размещения iDatabaseDriver. Вы можете поместить его в базу данных или под водителями. Лично я бы поместил его в базу данных, так как он находился близко к тому, где он нужен (поскольку более вероятно, что Database требует iDatabaseDriver, поэтому зависимость существует).

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

Теперь этот пример представляет собой грубое упрощение, но я думаю, что он должен понять суть.

• У вас есть правила для именования и хранения интерфейсов.

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

• Соблюдайте эти правила!

  Это более важно, чем правила. Если вы не следуете правилам, это хуже, чем не иметь их вообще, так как вы ожидаете чего-то, что не произойдет.

• Благоприятные семантические отношения над отношениями на уровне кода

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

Изменить: Что касается именования и вашего редактирования:

Лично я ненавижу такие вещи, как Database_Database. Хотя это может иметь смысл с учетом структуры приложения, оно не имеет никакого смыслового смысла. Вместо этого то, что мне нравится делать в автозагрузчике (-ах), - это проверить файл, и если он не существует, но каталог делает это, проверьте тот же файл внутри этого каталога. Таким образом, Database приведет к проверке /database.php, и если это не удастся, /database/database.php. Это устраняет необходимость двойного именования. Database_DatabaseAbstract станет Database_Abstract. Таким образом, ваш Database_Mysql_Database может стать Database_Mysql сохраненным в /database/mysql/mysql.php (который мне кажется более чистым).

Что касается вашего соглашения об именах абстрактных классов и того, я лично предпочитаю идентифицировать интерфейсы по имени. Это упрощает понимание с первого взгляда (вы знаете, что public function foo(iDatabase $database) ищет экземпляр интерфейса вместо абстрактного класса или конкретного класса). Теперь есть два реальных способа сделать это.

• Добавить Interface в имя, поэтому Database_Database станет Database_Interface. Я лично считаю, что это слишком многословно для моих потребностей, однако преимущество здесь в том, что все ваши специальные типы классов (Исключения, Интерфейсы, Итераторы и т.д.) Можно просто сопоставить таким образом. Имя класса говорит вам, что именно вы имеете без какой-либо двусмысленности.

• Подготовьте всю последовательность с помощью i. Таким образом, Database_Database станет iDatabase, которое затем будет переведено в автозагрузчик на /database/interface.php. Тогда, если бы у вас были более глубокие интерфейсы, iDatabase_Mysql_Query мог бы работать (что бы отображалось на /database/mysql/query/interface.php.

Что касается абстрактного класса, я бы этого не сделал. Тот факт, что класс является абстрактным, не должен иметь никакого отношения к его смысловому смыслу. Абстрактная природа - это кодирующая конструкция, а не семантическая (абстрактный класс используется не что иное, как наследование, так как вы используете интерфейс для проверки типов). Поэтому я бы не рекомендовал включать Abstract в имя класса. Просто назовите его Database и сделайте это. Он читается лучше семантически (IMHO) и передает то же значение.

Я надеюсь, что это поможет и имеет смысл...

Ответ 2

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

• со стандартными соглашениями об именах вы вызываете интерфейсы Database и Router, а не iDatabase и iRouter.

• не думайте о производительности перед профилированием: как вы можете быть уверены, что влияние наличия всех интерфейсов, анализируемых с каждым единственным запросом, не компенсирует загрузку многих файлов? файлы все равно будут в буфере.

EDIT: (после того, как вопрос был отредактирован).

Вы хотите:

• База данных (classes/Database.php), интерфейс для ввода типа/завершения кода (если вы настаиваете на наличии интерфейса в первую очередь, но мы не обсуждаем это);
• Database_Abstract (classes/Database/Abstract.php), класс, который реализует базу данных и имеет общую абстрактную функциональность; пользователи никогда не знают, что он существует;
• Database_Mysql (classes/Database/Mysql.php), класс, который расширяет Database_Abstract. Он не должен реализовывать базу данных (Database_Abstract уже делает это);

Вы также можете добавить все пути (и имена) к имени своей структуры; таким образом, если вы используете некоторые классы из ZF, скажем, для генерации PDF, вы можете сохранить один и тот же автозагрузчик и один и тот же каталог классов, а не смешивать два.

Если вы действительно влюблены в ООП, вы можете добавить:

• Database_Factory (классы/база данных / Factory.php) - класс, который имеет один метод, называемый createDatabase; метод имеет комментарий к doc/** @returns Database */и принимает конфигурацию базы данных (в виде строки или, может быть, массива или, возможно, объекта Database_Config, если вы являетесь жестким ядром); это должно было бы действительно отделить реализацию от интерфейса.

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

Ответ 3

В общем, старайтесь:

• Используйте автозагрузчик.
• Один файл содержит один класс.
• Храните интерфейсы рядом с их конкретными реализациями.

Вот хорошая статья по теме:

http://weierophinney.net/matthew/archives/254-Why-PHP-Namespaces-Matter.html

Ответ 4

Если вы используете соглашения об именах PEAR или Zend, интерфейс будет находиться в папке с компонентами.

I.e., класс Myprefix_Router_Interface переводится в путь /Myprefix/Router/Interface.php

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