=encoding utf8

=for comment
Последовательное форматирование этого файла осуществляется с:
  perl ./Porting/podtidy pod/perlootut.pod

=head1 NAME/НАИМЕНОВАНИЕ

perlootut - учебник Объектно-Ориентированного программирования на Perl

=head1 DATE

Этот документ был создан в феврале 2011 года, и последний крупный пересмотр был в феврале 2013 года.

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

=head1 ОПИСАНИЕ

Этот документ представляет собой введение в объектно ориентированное программирование на Perl.
Она начинается с краткого обзора концепции объектно-ориентированного проектирования.
Затем он рассказывает о нескольких различных OO системах из L<CPAN|http://search.cpan.org> ,
которые являются вершиной того, что может предоставить Perl.

По умолчанию встроенная в Perl OO система является минималистичной, она оставляет вам делать 
большую часть работы. Этот минимализм имел много смысла в 1994 году, но через годы, начиная 
с Perl 5.0 мы увидели появление ряда общих шаблонов в Perl OO. К счастью гибкость Perl 
 позволяет создавать богатые и процветающие экосистемы OO Perl.

Если вы хотите знать, как Perl OO работает под капотом,
в документе L<perlobj> объясняются все мелкие детали.

Этот документ предполагает, что вы уже понимаете основы синтаксиса Perl,
типы переменных, операторов и вызовов подпрограмм. Если вы не понимаете 
эти концепции еще, пожалуйста, прочитайте  L<perlintro> сначала. 
Вы также должны прочитать документы L<perlsyn>, L<perlop>, и L<perlsub>.

=head1 ОСНОВЫ ОБЪЕКТНО ОРИЕНТИРОВАННОСТИ

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

Система OO Perl основана на классе. Классовое основание ОО систем
является довольно распространенным явлением. Оно используется в
Java, C++, C#, Python, Ruby и многими другими языками. Также существуют другие
парадигмы объектно-ориентированности. JavaScript — это наиболее популярный
язык для использования в другой парадигме. Системы OO JavaScript основаны на 
прототипах.

=head2 Объект

B<Объект> — это структура данных, которая объединяет вместе данные и 
подпрограммы, которые обрабатывают эти данные. Данные объекта называются 
B<атрибутами>, а его подпрограммы, называются B<методами>. Объект можно рассматривать 
как существительное (человек, веб-служба, компьютер).

Объект представляет одну дискретных вещь. Например, объект может 
представлять файл. Атрибуты файла-объекта могут включать путь,содержание
и последние изменения. Если мы создали объект для представления
F</etc/hostname> на машине с именем "foo.example.com", то путь объекта будет
"/etc/hostname", его содержание будет "foo\n", и время последнего 
изменения будет 1304974868 секунд, прошедших с начала эпохи.

Методы, связанные с файлом могут включать C<rename()> и C<write()>.

В Perl большинство объектов являются хэшами, но в OO системах, 
которые мы рекомендуем, вам не будет необходимости беспокоиться 
об этом. На практике это лучше рассматривать, как  внутреннюю непрозрачную 
структуру данных объекта.

=head2 Класс

B<Класс> определяет поведение категории объектов. Класс является именем категории
(например, "Файл"), и класс также определяет поведение объектов в данной категории.

Все объекты принадлежат к определенному классу. Например наш F</etc/hostname>
объект принадлежит к классу C<File> . Когда мы хотим создать определенный объект, 
мы начинаем с его класса и B<создаем> или B<инициализируем> (B<instantiate>) 
экземпляр объекта. Конкретный 
объект часто именуется как C<экземпляр> (B<instance>) класса.

В Perl любой пакет может быть классом. Разница между пакетом, 
который является классом и пакетом не являющимся классом состоит в том, как 
используется пакет. Вот наше "объявление класса" для класса C<File>:

  package File;

В Perl Существует нет специального ключевого слова для построения объекта.
Однако большинство OO модулей на CPAN использовать метод с именем C<new()>, 
 чтобы создать новый объект:

  my $hostname = File->new(
      path          => '/etc/hostname',
      content       => "foo\n",
      last_mod_time => 1304974868,
  );

(Не беспокойтесь оператор C<< -> >> будет объяснен позже.)

=head3 Благословение (Blessing)

Как мы уже говорили ранее, большинство Perl объектов хэши, 
но объект может быть экземпляром любого типа данных Perl (скалярами,
массивами, и т.д.). Превращение структуру простых данных в объект 
осуществляется B<благословением>  B<blessing>() данной структуры с
использованием Perl функции C<bless>.

Хотя мы настоятельно рекомендуем вам не строить объекты с нуля, 
вы должны знать, термин, B<благословлять> (B<bless>). 
B<Благословленная> (<blessed>) структура данных (ака "ссылка") — это объект. 
Мы иногда говорим, что объект был "благословлен в класс" ("blessed into a class").

После того, как ссылка была благословлена, функция  C<blessed> из модуля
ядра L<Scalar::Util> может сказать нам  имя ее класса. Эта подпрограмма 
возвращает объект класса, если она видит, что передали объект и ложь 
(false) в противном случае.

  use Scalar::Util 'blessed';

  print blessed($hash);      # undef
  print blessed($hostname);  # File

=head3 Конструктор

B<Конструктор> создает новый объект. В Perl конструктор класса 
— это просто еще один метод, в отличие от некоторых других языков, 
которые предоставляют синтаксис для конструкторов. Большинство классов
Perl использовать C<new> как имя для их конструктора:

  my $file = File->new(...);

=head2 Методы

Вы уже узнали, что B<методом> является подпрограмма, которая работает
с объектом. Вы можете думать о методе как о вещи, которую объект может делать.
Если объект является существительным, то методы будут его глаголами
(сохранить, печатать, открывать).

В Perl методы являются просто подпрограммами, которые живут в классе пакета. 
Методы всегда записываются так, чтобы получить объект в качестве первого аргумента.

  sub print_info {
      my $self = shift;

      print "This file is at ", $self->path, "\n";
  }

  $file->print_info;
  # The file is at /etc/hostname

Что делает метод специальным так это то, I<как он вызывается>. 
Оператора стрелка (C<< -> >>) говорит Perl, что мы вызываем метод.

Когда мы делаем вызов метода, Perl делает так, что
 в качестве первого аргумента передается B<вызыватель> (B<invocant>).
 B<вызыватель> (B<Invocant>) это причудливое название для вещи с левой стороны 
 стрелки. Вызывателем (Invocant) может быть или имя класса или имя объекта. 
 Мы также можем передать дополнительные аргументы в метод:

  sub print_info {
      my $self   = shift;
      my $prefix = shift // "This file is at ";

      print $prefix, ", ", $self->path, "\n";
  }

  $file->print_info("The file is located at ");
  # The file is located at /etc/hostname

=head2 Атрибуты

Каждый класс может определить свои B<атрибуты>.
Когда мы создаем экземпляр объекта, мы присваиваем значения этим
атрибутам. Например каждый объект  C<File> имеет путь. 
Атрибуты, иногда называются B<свойствами> (B<properties>).

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

Мы рекомендуем, что вы имели доступ к атрибутам только через методы B<доступа> ( B<accessor> methods).
Это методы, с помощью которых можно получить или задать значение каждого атрибута. 
Мы видели это раньше в примере C<print_info()>, который вызывает C<<$self->path >>.

Вы также можете знать термины B<геттер> и B<сеттер> (B<getter> и B<setter>). 
Это два типа доступа. Геттер получает значение атрибута, 
в то время как сеттер устанавливает его. Еще один термин для сеттера это B<мутатор> (B<mutator>)

Атрибуты обычно определяются как только для чтения (read-only) или для чтения и записи ( read-write). 
Атрибуты только для чтения(read-only) устанавливаются только, когда создается
объект, в то время как атрибуты чтения-записи(read-write) могут быть изменены в любое время.

Значением атрибута может быть другой объект. Например
вместо возвращения времени последней модификации (mod time) в виде числа, класс 
 C<File> может вернуть объект L<DateTime>, представляющий это значение.

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

=head2 Полиморфизм

B<Полиморфизм> -это причудливый способ сказать, что 
объекты из двух различных классов используют единое API.
Например мы могли бы иметь классы C<File> и C<WebPage> , которые
оба имеют метод C<print_content()>. Этот метод может создавать
разные выходные данные для каждого класса, но они имеют общий интерфейс (common interface).

В то время как два класса могут отличаться во многих отношениях,
но, когда речь заходит о методе C<print_content()>, то они одинаковы. Это 
означает, что мы можем попытаться вызвать метод C<print_content()>
 на объекте класса, и B<нам не нужно знать, какому классу принадлежит объект!>

Полиморфизм — одна из ключевых концепций объектно ориентированного проектирования(object-oriented design).

=head2 Наследование

B<Inheritance> lets you create a specialized version of an existing
class. Inheritance lets the new class reuse the methods and attributes
of another class.

For example, we could create an C<File::MP3> class which B<inherits>
from C<File>. An C<File::MP3> B<is-a> I<more specific> type of C<File>.
All mp3 files are files, but not all files are mp3 files.

We often refer to inheritance relationships as B<parent-child> or
C<superclass/subclass> relationships. Sometimes we say that the child
has an B<is-a> relationship with its parent class.

C<File> is a B<superclass> of C<File::MP3>, and C<File::MP3> is a
B<subclass> of C<File>.

  package File::MP3;

  use parent 'File';

The L<parent> module is one of several ways that Perl lets you define
inheritance relationships.

Perl allows multiple inheritance, which means that a class can inherit
from multiple parents. While this is possible, we strongly recommend
against it. Generally, you can use B<roles> to do everything you can do
with multiple inheritance, but in a cleaner way.

Note that there's nothing wrong with defining multiple subclasses of a
given class. This is both common and safe. For example, we might define
C<File::MP3::FixedBitrate> and C<File::MP3::VariableBitrate> classes to
distinguish between different types of mp3 file.

=head3 Overriding methods and method resolution

Inheritance allows two classes to share code. By default, every method
in the parent class is also available in the child. The child can
explicitly B<override> a parent's method to provide its own
implementation. For example, if we have an C<File::MP3> object, it has
the C<print_info()> method from C<File>:

  my $cage = File::MP3->new(
      path          => 'mp3s/My-Body-Is-a-Cage.mp3',
      content       => $mp3_data,
      last_mod_time => 1304974868,
      title         => 'My Body Is a Cage',
  );

  $cage->print_info;
  # The file is at mp3s/My-Body-Is-a-Cage.mp3

If we wanted to include the mp3's title in the greeting, we could
override the method:

  package File::MP3;

  use parent 'File';

  sub print_info {
      my $self = shift;

      print "This file is at ", $self->path, "\n";
      print "Its title is ", $self->title, "\n";
  }

  $cage->print_info;
  # The file is at mp3s/My-Body-Is-a-Cage.mp3
  # Its title is My Body Is a Cage

The process of determining what method should be used is called
B<method resolution>. What Perl does is look at the object's class
first (C<File::MP3> in this case). If that class defines the method,
then that class's version of the method is called. If not, Perl looks
at each parent class in turn. For C<File::MP3>, its only parent is
C<File>. If C<File::MP3> does not define the method, but C<File> does,
then Perl calls the method in C<File>.

If C<File> inherited from C<DataSource>, which inherited from C<Thing>,
then Perl would keep looking "up the chain" if necessary.

It is possible to explicitly call a parent method from a child:

  package File::MP3;

  use parent 'File';

  sub print_info {
      my $self = shift;

      $self->SUPER::print_info();
      print "Its title is ", $self->title, "\n";
  }

The C<SUPER::> bit tells Perl to look for the C<print_info()> in the
C<File::MP3> class's inheritance chain. When it finds the parent class
that implements this method, the method is called.

We mentioned multiple inheritance earlier. The main problem with
multiple inheritance is that it greatly complicates method resolution.
See L<perlobj> for more details.

=head2 Encapsulation

B<Encapsulation> is the idea that an object is opaque. When another
developer uses your class, they don't need to know I<how> it is
implemented, they just need to know I<what> it does.

Encapsulation is important for several reasons. First, it allows you to
separate the public API from the private implementation. This means you
can change that implementation without breaking the API.

Second, when classes are well encapsulated, they become easier to
subclass. Ideally, a subclass uses the same APIs to access object data
that its parent class uses. In reality, subclassing sometimes involves
violating encapsulation, but a good API can minimize the need to do
this.

We mentioned earlier that most Perl objects are implemented as hashes
under the hood. The principle of encapsulation tells us that we should
not rely on this. Instead, we should use accessor methods to access the
data in that hash. The object systems that we recommend below all
automate the generation of accessor methods. If you use one of them,
you should never have to access the object as a hash directly.

=head2 Composition

In object-oriented code, we often find that one object references
another object. This is called B<composition>, or a B<has-a>
relationship.

Earlier, we mentioned that the C<File> class's C<last_mod_time>
accessor could return a L<DateTime> object. This is a perfect example
of composition. We could go even further, and make the C<path> and
C<content> accessors return objects as well. The C<File> class would
then be B<composed> of several other objects.

=head2 Roles

B<Roles> are something that a class I<does>, rather than something that
it I<is>. Roles are relatively new to Perl, but have become rather
popular. Roles are B<applied> to classes. Sometimes we say that classes
B<consume> roles.

Roles are an alternative to inheritance for providing polymorphism.
Let's assume we have two classes, C<Radio> and C<Computer>. Both of
these things have on/off switches. We want to model that in our class
definitions.

We could have both classes inherit from a common parent, like
C<Machine>, but not all machines have on/off switches. We could create
a parent class called C<HasOnOffSwitch>, but that is very artificial.
Radios and computers are not specializations of this parent. This
parent is really a rather ridiculous creation.

This is where roles come in. It makes a lot of sense to create a
C<HasOnOffSwitch> role and apply it to both classes. This role would
define a known API like providing C<turn_on()> and C<turn_off()>
methods.

Perl does not have any built-in way to express roles. In the past,
people just bit the bullet and used multiple inheritance. Nowadays,
there are several good choices on CPAN for using roles.

=head2 When to Use OO

Object Orientation is not the best solution to every problem. In I<Perl
Best Practices> (copyright 2004, Published by O'Reilly Media, Inc.),
Damian Conway provides a list of criteria to use when deciding if OO is
the right fit for your problem:

=over 4

=item *

The system being designed is large, or is likely to become large.

=item *

The data can be aggregated into obvious structures, especially if
there's a large amount of data in each aggregate.

=item *

The various types of data aggregate form a natural hierarchy that
facilitates the use of inheritance and polymorphism.

=item *

You have a piece of data on which many different operations are
applied.

=item *

You need to perform the same general operations on related types of
data, but with slight variations depending on the specific type of data
the operations are applied to.

=item *

It's likely you'll have to add new data types later.

=item *

The typical interactions between pieces of data are best represented by
operators.

=item *

The implementation of individual components of the system is likely to
change over time.

=item *

The system design is already object-oriented.

=item *

Large numbers of other programmers will be using your code modules.

=back

=head1 PERL OO SYSTEMS

As we mentioned before, Perl's built-in OO system is very minimal, but
also quite flexible. Over the years, many people have developed systems
which build on top of Perl's built-in system to provide more features
and convenience.

We strongly recommend that you use one of these systems. Even the most
minimal of them eliminates a lot of repetitive boilerplate. There's
really no good reason to write your classes from scratch in Perl.

If you are interested in the guts underlying these systems, check out
L<perlobj>.

=head2 Moose

L<Moose> bills itself as a "postmodern object system for Perl 5". Don't
be scared, the "postmodern" label is a callback to Larry's description
of Perl as "the first postmodern computer language".

C<Moose> provides a complete, modern OO system. Its biggest influence
is the Common Lisp Object System, but it also borrows ideas from
Smalltalk and several other languages. C<Moose> was created by Stevan
Little, and draws heavily from his work on the Perl 6 OO design.

Here is our C<File> class using C<Moose>:

  package File;
  use Moose;

  has path          => ( is => 'ro' );
  has content       => ( is => 'ro' );
  has last_mod_time => ( is => 'ro' );

  sub print_info {
      my $self = shift;

      print "This file is at ", $self->path, "\n";
  }

C<Moose> provides a number of features:

=over 4

=item * Declarative sugar

C<Moose> provides a layer of declarative "sugar" for defining classes.
That sugar is just a set of exported functions that make declaring how
your class works simpler and more palatable.  This lets you describe
I<what> your class is, rather than having to tell Perl I<how> to
implement your class.

The C<has()> subroutine declares an attribute, and C<Moose>
automatically creates accessors for these attributes. It also takes
care of creating a C<new()> method for you. This constructor knows
about the attributes you declared, so you can set them when creating a
new C<File>.

=item * Roles built-in

C<Moose> lets you define roles the same way you define classes:

  package HasOnOfSwitch;
  use Moose::Role;

  has is_on => (
      is  => 'rw',
      isa => 'Bool',
  );

  sub turn_on {
      my $self = shift;
      $self->is_on(1);
  }

  sub turn_off {
      my $self = shift;
      $self->is_on(0);
  }

=item * A miniature type system

In the example above, you can see that we passed C<< isa => 'Bool' >>
to C<has()> when creating our C<is_on> attribute. This tells C<Moose>
that this attribute must be a boolean value. If we try to set it to an
invalid value, our code will throw an error.

=item * Full introspection and manipulation

Perl's built-in introspection features are fairly minimal. C<Moose>
builds on top of them and creates a full introspection layer for your
classes. This lets you ask questions like "what methods does the File
class implement?" It also lets you modify your classes
programmatically.

=item * Self-hosted and extensible

C<Moose> describes itself using its own introspection API. Besides
being a cool trick, this means that you can extend C<Moose> using
C<Moose> itself.

=item * Rich ecosystem

There is a rich ecosystem of C<Moose> extensions on CPAN under the
L<MooseX|http://search.cpan.org/search?query=MooseX&mode=dist>
namespace. In addition, many modules on CPAN already use C<Moose>,
providing you with lots of examples to learn from.

=item * Many more features

C<Moose> is a very powerful tool, and we can't cover all of its
features here. We encourage you to learn more by reading the C<Moose>
documentation, starting with
L<Moose::Manual|http://search.cpan.org/perldoc?Moose::Manual>.

=back

Of course, C<Moose> isn't perfect.

C<Moose> can make your code slower to load. C<Moose> itself is not
small, and it does a I<lot> of code generation when you define your
class. This code generation means that your runtime code is as fast as
it can be, but you pay for this when your modules are first loaded.

This load time hit can be a problem when startup speed is important,
such as with a command-line script or a "plain vanilla" CGI script that
must be loaded each time it is executed.

Before you panic, know that many people do use C<Moose> for
command-line tools and other startup-sensitive code. We encourage you
to try C<Moose> out first before worrying about startup speed.

C<Moose> also has several dependencies on other modules. Most of these
are small stand-alone modules, a number of which have been spun off
from C<Moose>. C<Moose> itself, and some of its dependencies, require a
compiler. If you need to install your software on a system without a
compiler, or if having I<any> dependencies is a problem, then C<Moose>
may not be right for you.

=head3 Moo

If you try C<Moose> and find that one of these issues is preventing you
from using C<Moose>, we encourage you to consider L<Moo> next. C<Moo>
implements a subset of C<Moose>'s functionality in a simpler package.
For most features that it does implement, the end-user API is
I<identical> to C<Moose>, meaning you can switch from C<Moo> to
C<Moose> quite easily.

C<Moo> does not implement most of C<Moose>'s introspection API, so it's
often faster when loading your modules. Additionally, none of its
dependencies require XS, so it can be installed on machines without a
compiler.

One of C<Moo>'s most compelling features is its interoperability with
C<Moose>. When someone tries to use C<Moose>'s introspection API on a
C<Moo> class or role, it is transparently inflated into a C<Moose>
class or role. This makes it easier to incorporate C<Moo>-using code
into a C<Moose> code base and vice versa.

For example, a C<Moose> class can subclass a C<Moo> class using
C<extends> or consume a C<Moo> role using C<with>.

The C<Moose> authors hope that one day C<Moo> can be made obsolete by
improving C<Moose> enough, but for now it provides a worthwhile
alternative to C<Moose>.

=head2 Class::Accessor

L<Class::Accessor> is the polar opposite of C<Moose>. It provides very
few features, nor is it self-hosting.

It is, however, very simple, pure Perl, and it has no non-core
dependencies. It also provides a "Moose-like" API on demand for the
features it supports.

Even though it doesn't do much, it is still preferable to writing your
own classes from scratch.

Here's our C<File> class with C<Class::Accessor>:

  package File;
  use Class::Accessor 'antlers';

  has path          => ( is => 'ro' );
  has content       => ( is => 'ro' );
  has last_mod_time => ( is => 'ro' );

  sub print_info {
      my $self = shift;

      print "This file is at ", $self->path, "\n";
  }

The C<antlers> import flag tells C<Class::Accessor> that you want to
define your attributes using C<Moose>-like syntax. The only parameter
that you can pass to C<has> is C<is>. We recommend that you use this
Moose-like syntax if you choose C<Class::Accessor> since it means you
will have a smoother upgrade path if you later decide to move to
C<Moose>.

Like C<Moose>, C<Class::Accessor> generates accessor methods and a
constructor for your class.

=head2 Object::Tiny

Finally, we have L<Object::Tiny>. This module truly lives up to its
name. It has an incredibly minimal API and absolutely no dependencies
(core or not). Still, we think it's a lot easier to use than writing
your own OO code from scratch.

Here's our C<File> class once more:

  package File;
  use Object::Tiny qw( path content last_mod_time );

  sub print_info {
      my $self = shift;

      print "This file is at ", $self->path, "\n";
  }

That's it!

With C<Object::Tiny>, all accessors are read-only. It generates a
constructor for you, as well as the accessors you define.

=head2 Role::Tiny

As we mentioned before, roles provide an alternative to inheritance,
but Perl does not have any built-in role support. If you choose to use
Moose, it comes with a full-fledged role implementation. However, if
you use one of our other recommended OO modules, you can still use
roles with L<Role::Tiny>

C<Role::Tiny> provides some of the same features as Moose's role
system, but in a much smaller package. Most notably, it doesn't support
any sort of attribute declaration, so you have to do that by hand.
Still, it's useful, and works well with C<Class::Accessor> and
C<Object::Tiny>

=head2 OO System Summary

Here's a brief recap of the options we covered:

=over 4

=item * L<Moose>

C<Moose> is the maximal option. It has a lot of features, a big
ecosystem, and a thriving user base. We also covered L<Moo> briefly.
C<Moo> is C<Moose> lite, and a reasonable alternative when Moose
doesn't work for your application.

=item * L<Class::Accessor>

C<Class::Accessor> does a lot less than C<Moose>, and is a nice
alternative if you find C<Moose> overwhelming. It's been around a long
time and is well battle-tested. It also has a minimal C<Moose>
compatibility mode which makes moving from C<Class::Accessor> to
C<Moose> easy.

=item * L<Object::Tiny>

C<Object::Tiny> is the absolute minimal option. It has no dependencies,
and almost no syntax to learn. It's a good option for a super minimal
environment and for throwing something together quickly without having
to worry about details.

=item * L<Role::Tiny>

Use C<Role::Tiny> with C<Class::Accessor> or C<Object::Tiny> if you
find yourself considering multiple inheritance. If you go with
C<Moose>, it comes with its own role implementation.

=back

=head2 Other OO Systems

There are literally dozens of other OO-related modules on CPAN besides
those covered here, and you're likely to run across one or more of them
if you work with other people's code.

In addition, plenty of code in the wild does all of its OO "by hand",
using just the Perl built-in OO features. If you need to maintain such
code, you should read L<perlobj> to understand exactly how Perl's
built-in OO works.

=head1 CONCLUSION

As we said before, Perl's minimal OO system has led to a profusion of
OO systems on CPAN. While you can still drop down to the bare metal and
write your classes by hand, there's really no reason to do that with
modern Perl.

For small systems, L<Object::Tiny> and L<Class::Accessor> both provide
minimal object systems that take care of basic boilerplate for you.

For bigger projects, L<Moose> provides a rich set of features that will
let you focus on implementing your business logic.

We encourage you to play with and evaluate L<Moose>,
L<Class::Accessor>, and L<Object::Tiny> to see which OO system is right
for you.

=head1 ПЕРЕВОДЧИКИ
 
=over
 
=item * Николай Мишин C<< <mi@ya.ru> >>

=back

