Наши любимые дети

=Intro

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

=Быстрое_погружение

Начну с примера в котором явно выражены архитектурные проблемы. Встречаем horror.pl:

#!/usr/bin/perl

use lib::abs qw( base_lib lib );
use JIP::ToolSet;
use Reporter;

Reporter->new()->send_reports();

Reporter.pm:

package Reporter;

use parent qw( Class::Base );
use JIP::ToolSet;
use Carp qw( croak );
use ReportBuilder;
use ReportSender;

sub send_reports {
    my $self = shift;

    my @reports = ReportBuilder->new()->create_reports();

    croak 'no reports exception' unless @reports;

    my $report_sender = ReportSender->new();

    for my $each_report ( @reports ) {
        $report_sender->send( $each_report );
    }
}

1;

Устроен Reporter очень просто. В единственном методе send_reports() он получает список репортов, рапортует о проблемах если репорты отсутствуют, рассылает репорты адресатам. Даже у такой простой архитектуры может быть много врожденных пороков...

Тестируемость:
-- даже для случая когда @reports пуст (попытка вызвать исключение) придется изрядо напрячь извилины. плохое тестовое покрытие усложняет внесение изменений.

Связанность:
-- знает о том что именно ReportBuilder создает отчеты и умеет инстанцировать ReportBuilder.
-- знает о том что именно ReportSender отправляет отчеты и умеет инстанцировать ReportSender.

Сопротивление изменениям:
-- предположим что ReportSender надо заменить на другой concrete-репортер (например SMTP будет вытеснен XMPP).
-- предположим что у ReportBuilder появятся именованные параметры в конструкторе.

Таким образом получен довольно яркий пример нарушения принципа инверсии зависимостей.
 
=Работа_над_ошибками

Вношу простые изменения. Для начала заменю зависимость от конкретных реализаций ReportBuilder и ReportSender на зависимость от абстракций (а вот здесь важно учитывать специфику опубликованных интерфейсов). Классы  "билдер" и "сендер" будут инстанцироваться вне send_reports() и экземпляры этих классов будут получены конструктором Reporter::new():

#!/usr/bin/perl

use lib::abs qw( base_lib lib );
use JIP::ToolSet;
use Reporter;
use ReportBuilder;
use ReportSender;

Reporter->new(
    builder => ReportBuilder->new(),
    sender  => ReportSender->new(),
)->send_reports();

Реализация send_reports() стала еще короче и нагляднее:

package Reporter;

use parent qw( Class::Base Class::Accessor::Fast );
use JIP::ToolSet;
use Carp qw( croak );

__PACKAGE__->mk_accessors( qw( _builder _sender ) );

sub init {
    my ( $self, $config ) = @_;

    # обязательные именованные параметры
    croak 'required parameter "builder" not defined'
        unless exists $config->{'builder'};

    croak 'required parameter "sender" not defined'
        unless exists $config->{'sender'};

    # собственно инициализация свойств объекта
    $self->_builder( $config->{'builder'} );
    $self->_sender( $config->{'sender'} );

    return $self;
}

sub send_reports {
    my $self = shift;

    my @reports = $self->_builder->create_reports();

    croak 'no reports exception' unless @reports;

    for my $each_report ( @reports ) {
        $self->_sender->send( $each_report );
    }
}

1;

Такой код уже намного легче тестировать. Новые свойства (_builder & _sender) я предпочел спрятать. Появилась зависимость от абстракций? Похоже что нет. Таков Perl. Надо помнить специфику опубликованных интерфейсов "билдер" и "сендер" тк в Perl отсутствуют такие усилители ООП-абстракций как interfaces в Java и .NET, зато есть смешные "роли" которыми можно играть подключив модули CPAN. Ниже смешной и бесполезный пример...

ReportBuilder.pm:

package ReportBuilder;

use parent qw( Class::Base );
use Class::Roles role => 'create_reports';

use JIP::ToolSet;

sub create_reports {
    my $self = shift;

    return qw( first_report second_report );
}

1;

ReportSender.pm:

package ReportSender;

use JIP::ToolSet;
use Class::Roles role => [ 'new', 'send' ];

sub new {
    # code
}

sub send {
    # code
}

1;

В конструкторе Reporter появились проверки (does()):

sub init {
    my ( $self, $config ) = @_;

    # обязательные именованные параметры
    croak 'required parameter "builder" not defined'
        unless exists $config->{'builder'};

    croak 'required parameter "sender" not defined'
        unless exists $config->{'sender'};

    # проверка соответствия интерфейсу (роли)
    croak 'is not a ReportBuilder'
        unless $config->{'builder'}->does('ReportBuilder');

    croak 'is not a ReportSender'
        unless $config->{'sender'}->does('ReportSender');

    # собственно инициализация свойств объекта
    $self->_builder( $config->{'builder'} );
    $self->_sender( $config->{'sender'} );

    return $self;
}

Вот теперь все готово. На практике реализован принцип инверсии зависимости. Репортер зависит только от интерфейсов. Все указанные проблемы решены. Можно писать более подробные тесты.

Десертный (как мне не хватает цветовой desert-темы в ЖЖ) кусок кода с фабрикой (о других вариантах в следующих статьях):

#!/usr/bin/perl

use lib::abs qw( base_lib lib );
use JIP::ToolSet;
use Reporter;
use ReportBuilderFactory;
use ReportSenderFactory;

Reporter->new(
    builder => ReportBuilderFactory->instantiate('tratata_report'),
    sender  => ReportSenderFactory->instantiate('XMPP'), # SMTP, STDOUT etc
)->send_reports();

=Outro

Теперь сам принцип...Принцип, который применен при отделении верхнего уровня от всех остальных, называется принципом инверсии зависимостей: «Модули верхних уровней не должны зависеть от модулей нижних уровней — и те, и другие должны зависить от абстракций».

=cut

Читайте также

Последние новости