Как важный это должно указать, реализует ли класс интерфейс в Perl?

Что ж, есть "утка", которую используют другие динамические языки. UNIVERSAL :: can выполняет это до такой степени, что другие языки склонны использовать его.

$unknown->doodle() if $unknown->can( 'doodle' );

Название «утка» набирается из идеи, что «если она ходит как утка и говорит как утка ... это утка». Тем не менее, мы не видим, идет ли он «как утка», мы просто видим, что он делает то, что кто-то называет «гулять», потому что это то, что мы называем, что делает утка. Например, объект Tree Walker не « гуляет » как утка!

Вы не захотите пропустить не тот объект определенными вещами.

$path_or_OS_I_dont_know_which->format( "c:", 'y' );

Итак, насколько хорошо работает типирование утки, зависит от ваших ожиданий с другой стороны. Плюс это имеет тенденцию становиться грязным, если контракт более сложен. Вы просто умножаете неопределенность - хотя сужение объектов за счет маловероятной вероятности того, что два класса случайно имеют 23 метода с одинаковыми именами.

if ( $duck->can( 'talk' ) && $duck->can( 'walk' )) { 
    $duck->walk();
    $duck->talk();
}

это хорошо, но

if ( $cand->can( 'walk' ) && $cand->can( 'talk' ) && ... && $cand->can( 'gargle' )) {
    ...
}

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

$cand->snicker() if $cand->can( 'snicker' );

(Конечно, соединения могут немного его очистить.)

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

Совместимо

У меня есть легкий шаблон, который я называю «Совместимо». Фактического пакета с таким названием не существует, но если класс реализует то, что делает Date , он помещает его в @ISA ;

our @ISA = qw<... Date::Compatible ...>;

Таким образом, есть только два isa , которые нужно вызвать - и я инкапсулирую это в подпрограмму is_one , так или иначе:

sub UNIVERSAL::is_one { 
    my ( $self, @args ) = @_;
    foreach my $pkg ( @args ) { 
        return 1 if $self->isa( $pkg );
    }
    return 0;
}

sub UNIVERSAL::is_compatible_with {
    my ( $self, $class ) = @_;
    return $self->is_one( $class, "${class}::Compatible" );
}

Это по крайней мере дает вещам контракт для выполнения и для запроса кода для проверки. Реализация все еще может решить, насколько важно выполнить определенный метод контракта, если он не требователен.

По-моему, это зависит от масштаба и очень субъективно. Чем больше система становится, тем более выгодно это для наращивания метаданные вокруг этого. Если Вы ожидаете, что это вырастет, это возможно эти сценарии использования изменение и сделает это стоящим времени для реализации. Но, жемчуг обычно приспосабливается к прагматическому программированию, код только, что необходимо и ничто больше. В Вашем случае, зная, что мало я знаю, я сказал бы, оставляют его, как. Если бы это был Java, то я был бы склонен склоняться другое направление, так как Java извлекает выгоду намного больше из интерфейсного использования от запуска.

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

С другой стороны, базовый класс может быть полезным как место для хранения POD. И определить некоторые константы... Сделайте у Вас есть Foo:: Type.pm? Если Вы делаете и обсуждаете generate_foo там, то нет никакой потребности в Generator.pm...

Да, это - личный выбор.

То, что я действительно хочу знать, - то, почему Вы говорите о

my $bar_foo = Foo::Type::Bar->generate_foo

вместо

my $bar_foo = Foo::Type::Bar::generate_foo

В первом случае существует тонкая фанера OO, которое предполагает, что своего рода OO / наследование могло бы быть на картах; но смотря на возражения Вашего коллеги на добавление явного наследования от пустого класса, кажется довольно ясным, что generate_foo называют способом неOO, и что никакое наследование не ожидается.

Имея это в виду, никто никогда не будет вводить

if (Foo::Type::Bar->isa('Foo::Type')) { ... }

сразу прежде

my $bar_foo = Foo::Type::Bar::generate_foo;

поскольку они могут сказать довольно быстро ли Foo:: Введите:: Панель имеет функцию generate_foo, и они решат это, когда они напишут свой код. Похоже, что Вы ищете некоторый, "мы делаем правильную вещь" утверждения, когда на самом деле, если немного кода понимает то утверждение превратно, это откажет в первый раз, когда это выполняется.

Похоже, что Вы имеете дело с кодом неOO, в этом случае я не применил бы стандартные методы OO к проблеме. Возможно, взгляд на статью Joel Spolsky о том, почему Венгерская запись может быть в порядке, сделанная правильно. При создании этого очевидным, если код является правильным или неправильным, Вы не должны волноваться о содержании руки или осуществлении мало-необходимых стандартов.

Вообще говоря, если у Вас есть "пустой" уровень в Вашей иерархии наследования, или что-то должно быть в ней, что Вы еще не факторизовали, или, если действительно нет ничего, чтобы вставить ее, это не должно быть там вообще. Я думаю, что это - источник дискомфорта Вашего друга с Foo::Type класс - нет никакой причины, которой это должно быть там; это просто, поскольку Вы в настоящее время описываете код.

Уровни вне первого в Вашей иерархии классов должны служить для дифференциации нескольких вещей на том уровне. Иначе люди будут искать причину уровня, чтобы быть там, даже если не будет ни одного: Я мог бы предложить на самом деле устранить средний уровень в целом. То, что это имеет имя, которое является семантически пустым (Type) указывает, что это не действительно необходимо. Возможно, существует несоответствие в Ваших взглядах о том, что объекты и что они, как предполагается, делают по сравнению с Вашим соглашением о присвоении имен.

Я мог бы обсудить это

Foo::Bar->generate
Foo::Baz->generate

имеет больше смысла, если возвращенные объекты зависят больше от их Bar- мыс или Baz- мыс для описания их, чем на их Type- мыс.

Действительно хороший способ оценить материал как это состоит в том, чтобы сказать себе, "Я поднял бы его на CPAN этот путь? Я хотел бы (потенциально), чтобы какой-либо программист Perl в мире видел это?" Если у Вас есть дискомфорт с тем (абсолютно пустой класс? Хм.) затем необходимо отступить и пересмотреть.