Moose对象基础教程：从Point示例探索

需积分: 12 119 浏览量更新于2024-07-17 收藏 284KB PDF 举报

"Moose CookBook - 理解 Moose 对象的基础与 Point 示例" 在 Perl 的 Moose 框架中，Moose CookBook 是一个非常重要的资源，它提供了关于如何使用 Moose 进行对象系统设计的实例和指导。这个文档以 "Moose::Cookbook::Basics::Recipe1" 开始，讲解了经典的 Point 示例，帮助开发者理解 Moose 对象实际上就是 Hashrefs。在标题 "Moose::Cookbook::Basics::Recipe1 - The (always classic) Point example." 中，"always classic" 指出 Point 类是面向对象编程中的一个基础示例，常用于教学和演示。这个例子同样来源于 Perl6 的 Apocalypse12 文档和经典的 K&R (Kernighan & Ritchie) 编程书籍。在 SYNOPSIS 部分，我们看到 Point 和 Point3D 两个类的定义。Point 类使用 `use Moose` 导入 Moose 模块，并声明了两个属性 `x` 和 `y`，它们都是可读写的整数（isa=>'Int'，is=>'rw'）。`required=>1` 表示这两个属性在构造时必须提供。Point 类还定义了一个 `clear` 方法，用于将点的位置重置为原点。 Point3D 类扩展了 Point 类（`extends 'Point'`），并添加了一个新的属性 `z`，同样为可读写的整数。此外，它还有一个 `after` 修饰器关联的 `clear` 方法，意味着在调用父类的 `clear` 方法后，会自动将 `z` 的值设为 0。在 DESCRIPTION 部分，强调了 Moose 类定义在包中，Moose 会自动开启 strict 和 warnings，确保代码的规范性。Moose 对象可以通过构造函数创建，可以接受哈希或哈希引用作为参数，如 `$point1`、`$point2` 和 `$point3d`。通过这个示例，我们可以学习到 Moose 如何简化 Perl 中的面向对象编程，包括属性声明、类型检查、方法定义以及继承。此外，Moose 还提供了诸如 `before`、`after` 和 `around` 等元编程特性，使我们可以更灵活地扩展和修改类的行为。这个基础示例是深入学习 Moose 及其在 Perl 中应用的良好起点。

}

};

package Person;

use Moose;

has 'first_name' => ( is => 'rw', isa => 'Str', required => 1 );

has 'last_name' => ( is => 'rw', isa => 'Str', required => 1 );

has 'middle_initial' => (

is => 'rw', isa => 'Str',

predicate => 'has_middle_initial'

);

has 'address' => ( is => 'rw', isa => 'Address' );

sub full_name {

my $self = shift;

return $self->first_name

. (

$self->has_middle_initial

? ' ' . $self->middle_initial . '. '

: ' '

) . $self->last_name;

}

package Employee;

use Moose;

extends 'Person';

has 'title' => ( is => 'rw', isa => 'Str', required => 1 );

has 'employer' => ( is => 'rw', isa => 'Company', weak_ref => 1 );

override 'full_name' => sub {

my $self = shift;

super() . ', ' . $self->title;

};

DESCRIPTION

This recipe introduces the subtype sugar function from Moose::Util::TypeConstraints. The subtype

function lets you declaratively create type constraints without building an entire class.

In the recipe we also make use of Locale::US and Regexp::Common to build constraints, showing

how constraints can make use of existing CPAN tools for data validation.

Finally, we introduce the required attribute option.

In the Address class we define two subtypes. The first uses the Locale::US module to check the

validity of a state. It accepts either a state abbreviation of full name.

A state will be passed in as a string, so we make our USState type a subtype of Moose's builtin Str

type. This is done using the as sugar. The actual constraint is defined using where. This function

accepts a single subroutine reference. That subroutine will be called with the value to be checked

in $_ (1). It is expected to return a true or false value indicating whether the value is valid for the

type.

We can now use the USState type just like Moose's builtin types:

has 'state' => ( is => 'rw', isa => 'USState' );

When the state attribute is set, the value is checked against the USState constraint. If the value is

not valid, an exception will be thrown.

The next subtype, USZipCode, uses Regexp::Common. Regexp::Common includes a regex for

validating US zip codes. We use this constraint for the zip_code attribute.

subtype 'USZipCode'

=> as Value

=> where {

/^$RE{zip}{US}{-extended => 'allow'}$/;

};

Using a subtype instead of requiring a class for each type greatly simplifies the code. We don't

really need a class for these types, as they're just strings, but we do want to ensure that they're

valid.

The type constraints we created are reusable. Type constraints are stored by name in a global

registry. This means that we can refer to them in other classes. Because the registry is global, we

do recommend that you use some sort of pseudo-namespacing in real applications, like

MyApp.Type.USState.

These two subtypes allow us to define a simple Address class.

Then we define our Company class, which has an address. As we saw in earlier recipes, Moose

automatically creates a type constraint for each our classes, so we can use that for the Company

class's address attribute:

has 'address' => ( is => 'rw', isa => 'Address' );

A company also needs a name:

has 'name' => ( is => 'rw', isa => 'Str', required => 1 );

This introduces a new attribute option, required. If an attribute is required, then it must be passed

to the class's constructor, or an exception will be thrown. It's important to understand that a

required attribute can still be false or undef, if its type constraint allows that.

The next attribute, employees, uses a parameterized type constraint:

has 'employees' => ( is => 'rw', isa => 'ArrayRef[Employee]' );

This constraint says that employees must be an array reference where each element of the array is

an Employee object. It's worth noting that an empty array reference also satisfies this constraint.

Parameterizable type constraints (or "container types"), such as ArrayRef[`a], can be made more

specific with a type parameter. In fact, we can arbitrarily nest these types, producing something like

HashRef[ArrayRef[Int]]. However, you can also just use the type by itself, so ArrayRef is legal.

(2)

If you jump down to the definition of the Employee class, you will see that it has an employer

attribute.

When we set the employees for a Company we want to make sure that each of these employee

objects refers back to the right Company in its employer attribute.

To do that, we need to hook into object construction. Moose lets us do this by writing a BUILD

method in our class. When your class defined a BUILD method, it will be called immediately after an

object construction, but before the object is returned to the caller (3).

The Company class uses the BUILD method to ensure that each employee of a company has the

proper Company object in its employer attribute:

sub BUILD {

my ( $self, $params ) = @_;

foreach my $employee ( @{ $self->employees || [] } ) {

$employee->employer($self);

}

The BUILD method is executed after type constraints are checked, so it is safe to assume that if

$self->employees has a value, it will be an array reference, and that the elements of that array

reference will be Employee objects.

We also want to make sure that whenever the employees attribute for a Company is changed, we

also update the employer for each employee.

To do this we can use an after modifier:

after 'employees' => sub {

my ( $self, $employees ) = @_;

foreach my $employee ( @{ $employees || [] } ) {

$employee->employer($self);

}

};

Again, as with the BUILD method, we know that the type constraint check has already happened, so

we know that if $employees is defined it will contain an array reference of Employee objects..

The Person class does not really demonstrate anything new. It has several required attributes. It

also has a predicate method, which we first used in recipe 3.

The only new feature in the Employee class is the override method modifier:

override 'full_name' => sub {

my $self = shift;

super() . ', ' . $self->title;

};

This is just a sugary alternative to Perl's built in SUPER:: feature. However, there is one difference.

You cannot pass any arguments to super. Instead, Moose simply passes the same parameters that

were passed to the method.

A more detailed example of usage can be found in

t/000_recipes/moose_cookbook_basics_recipe4.t.

剩余85页未读，继续阅读

drjiachen

粉丝: 172
资源: 2138

Moose对象基础教程：从Point示例探索

相场法建模

利用相场法模拟金属晶粒生长的计算代码

数字通信系统中的帧检测和频偏校正

如何在Windows系统上安装MOOSE

哪里可以查到moose的openfoam接口？

moose的make模块的使用方法

moose如何与openfoam集成

moose makefile文件

moose中的openfoam接口

如何用moose实现内聚力裂缝扩展

最新资源