Наименование интерфейсов / абстрактных классов в PHP 5.3 (с использованием пространств имен)

Question

До PHP 5.3 я называл интерфейсы / абстрактные классы так:

abstract class Framework_Package_Subpackage_Abstract {}
Framework/Package/Subpackage/Abstract.php

interface Framework_Package_Subpackage_Interface {}
Framework/Package/Subpackage/Interface.php

Теперь с PHP 5.3 и использованием пространств имен я больше не могу использовать свое соглашение, потому что interface и abstract являются зарезервированными ключевыми словами.

namespace Framework\Package\Subpackage;
abstract class Abstract {}
Framework/Package/Subpackage/Abstract.php

namespace Framework\Package\Subpackage;
interface Interface {}
Framework/Package/Subpackage/Interface.php

Итак, как мне назвать мои классы / интерфейсы?

Answer 1

Текущее руководство по кодированию "PSR-2" в основном предлагает вам сбросить интерфейс на один каталог и объединить имя.

Например:

File \Vendor\Foo\Interface.php ===> \Vendor\FooInterface.php.

и уровень использования, например:

use \Vendor\Foo\Interface; ===> use\Vendor\FooInterface;

см .: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

Answer 2

Об этом вопросе (Аннотация и Интерфейс) вы можете взглянуть на статью " Миграция ООП-библиотек и фреймворков в PHP 5.3 " в блоге Мэтью Вейера О'Финни - она ​​посвящена Zend Framework, и как они могли решить эту проблему в 2.0.

Одна из вещей, которые они отмечают:

На других языках ООП, таких как Python, C #, интерфейсы обозначаются как префикс интерфейса с большой буквы 'Я'; в приведенном выше примере мы бы тогда есть Zend :: View :: IView.

Итак, в вашем примере у вас будет что-то вроде этого, я думаю:

namespace Framework\Package\Subpackage;
abstract class ASubpackage {}
Framework/Package/Subpackage/ASubpackage.php

namespace Framework\Package\Subpackage;
interface ISubpackage {}
Framework/Package/Subpackage/ISubpackage.php

Что вы думаете об этом? (я не проверял этот способ, но это не выглядит как плохая идея?)

Answer 3

SubpackageAbstract, SubpackageInterface

Answer 4

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

Хороший пример использования общих описательных имен, указывающих на функциональность или поведение, можно найти в собственном SPL PHP, например: «Счетное», «Итератор», «ArrayObject».

Answer 5

Вы также можете сделать что-то вроде этого:

ЦСИ / Шахматы / Piece.php

<?php

namespace \Chess;

abstract class Piece implements \Chess\PieceInterface {}

ЦСИ / Шахматы / PieceInterface.php:

<?php

namespace \Chess;

interface PieceInterface {}

ЦСИ / Шахматы / шт / Pawn.php:

<?php

namespace \Chess\Piece;

class Pawn extends \Chess\Piece {}

Вот как я могу настроить автозагрузку в composer.json

{
    "autoload": {
        "psr-0": {
            "": "src/"
        }
    }
}

Answer 6

Честно говоря, я считаю, что венгерская нотация была введена в C #, потому что здесь нет ключевого слова "расширяет" и "внедряет", как в Java. Таким образом, чтобы дифференцировать соглашение стало называть его IView. В Java интерфейс будет называться только View, а реализации будут называться DefaultViewImpl, SmartyViewImpl или что-то в этом роде. Поскольку PHP имеет , расширяет и реализует ключевые слова, имеет смысл использовать соглашение Java. Я слышал аргумент, что венгерская нотация позволяет сделать элементы API идентифицируемыми, просто взглянув на имена классов. В этом случае я бы назвал это IView или AbstractView.

Answer 7

На мой взгляд, лучший способ решить эту проблему - просто добавить Class к своим именам классов.

namespace Framework\Package\Subpackage;
abstract class AbstractClass {}
Framework/Package/Subpackage/AbstractClass.php

namespace Framework\Package\Subpackage;
interface InterfaceClass {}
Framework/Package/Subpackage/InterfaceClass.php

обратите внимание, что это все еще не идеально (однако работает отлично), но я сохраняю код, похожий на оригинальную идею;)