反射

反射是指计算机程序在运行时可以访问、检测和修改它本身状态或行为的一种能力。通过将代码视为数据，这样就能像管理数据一样管理代码。听起来可能并没什么新奇的，但是这是对现代编程的深刻洞察，也是代码生成背后所遵循的原则。

检查模块是否被加载

如果你知道模块名字，你就可以通过查看%INC来检测模块是否被加载。当使用use或require加载代码时，Perl会在%INC中保存记录：键是模块的文件路径，值是该模块的在磁盘上的全路径。举个例子，加载 Modern::Perl时：

$INC{'Modern/Perl.pm'} = '.../lib/site_perl/5.12.1/Modern/Perl.pm';

#具体路径依赖你的安装路径，可能和这里不同。

要测试是否加载一个模块。就是看是否存在该键：

sub module_loaded
{
(my $modname = shift) =~ s!::!/!g;
return exists $INC{ $modname . '.pm' };
}

任何地方任何代码都可以操纵%INC。有时候这也有好处，比如 Test::MockObject和Test::MockModule就使用了该特性。

CPAN模块Class::Load的is_class_loaded()函数也能检测模块的加载。

检测一个包是否存在

任何继承UNIVERSAL的包都会提供一个can()方法。如果包不存在，Perl会抛出异常（无效的调用者），可以使用eval来包装下：

say "$pkg exists" if eval { $pkg->can( 'can' ) };

还有一种检测方法就是通过Perl的符号表。

检测一个类是否存在

因为在Perl中没办法严格的区分包和类，所以你可以使用检测包的方法来检查类，但是这不一定准确。

检测一个模块的版本

模块并非一定要提供版本号，但是每一个包都会从UNIVERSAL类继承VERSION()方法.

my $version = $module->VERSION;

VERSION() 返回模块的版本号（如果有）；否则返回undef；如果模块不存在也返回undef。

检测一个函数是否存在

通过将传参给can()函数来检测函数是否存在：

say "$func() exists" if $pkg->can( $func );

要注意的是在包没有预先声明或者重写了can()函数的情况下，在AUTOLOAD()里实现的函数可能检测不出来。

使用这个技术可以侦测模块的import()方法是否往当前名字空间里导入了一个函数：

say "$func() imported!" if __PACKAGE__->can( $func );

检测一个方法是否存在

暂时没有万无一失的方法来区分函数和方法。

去符号表里翻翻

符号表是一个特殊的哈希，键都是（包全局）符号的名字，值是类型团。类型团是一个内部数据结构，它可以包含一个标量、一个数组、一个哈希、一个文件句柄、一个函数，也可可以一次性包含所有这些。
在perldoc perlmod中可以查看有关符号表的细节。如果你真的想操作符号表和类型团，试试CPAN上的Package::Stash模块。

OO进阶

通过使用Moose，创建和使用面向对象变得非常简单。但是设计一个好的程序就没这么容易了，过度设计或设计得过少都不好。只有实践经验能帮助你掌握最重要的设计方法（技术），但这里仍然有些原则能够帮助到你：

优先使用组合而非继承

新手通常会过度使用继承特性，导致的结果就是类的层次变得很深，相互作用的关系变得复杂，这样的代码极难维护--谁知道该在哪个地方添加和修改？这处的代码和别处的代码发生冲突了会怎么样？

继承只是面向对象编程的其中一种工具，而且通常不是一个好的工具。
Car（车子）可以从Wheel（轮子）继承而来，但是更好的选择是Car（车子）包含几个Wheel（轮子）属性。

单一责任原则
当你设计一个对象时要考虑让对象的责任单一。例如，Employee对象可能有名字、联系方式、和其他的一些个人信息，而Job对象则是一些职责相关的信息。这样根据责任不同就划分出2个类：Employee类只需要关注是谁（个人信息相关）而不关心做什么；Job类则只需要关注做什么（职责相关）而不关心是谁来做。（比如2个员工可以做同一份工作，也可以一个员工同时做2份工作）

当每个类都是单一的责任时，就能减少耦合，提高封装。

别干重复的事（Don’t Repeat Yourself）

复杂性和重复让开发和维护变得困难。该原则（Don’t Repeat Yourself）提醒我们要找出并消除系统内部的重复部分--重复的代码、重复的数据。无论是配置文件还是用户数据，或者是其他重要的信息，都要将它们设计成单一的、规范的表示形式。这个原则可以帮助你找到系统和数据的最佳表示方式，并且能减少因重复而导致不同步的可能性。

里氏替换原则

里氏替换原则简单来说就是子类要能符合所以基类的要求，遵循该原则能保证基类被真正复用。这个原则很好理解，设想动物相当于基类，猫为子类。动物要求具有的特性，猫都会符合，根据里氏替换原则，在测试套件测试动物类时，用猫类来代替也应该能通过全部测试项。基类更具有普遍性，子类更具体。在使用基类的地方都能用子类替代，这就是里氏替换原则。

亚型和强制转换

Moose允许你声明和使用类型（Perl原生数据类型），并且还能扩展它们使用亚型（自创的类型）来形成更专业的数据表述。所有类型都有助于表达你的意图，有助于验证数据和方法是否适配。在必要时明确指定数据类型的强制转换。

例如，你期望一个日期类型的数据，但是外界输入通常是字符串类型。这时你可以自己新建一个日期的类型（这个类型是自创的，Perl语言哪有这种类型啊），并且增加从字符串到该日期类型的强制转换。这样就更容易让人明白你的代码意图。

Moose::Util::TypeConstraints 和MooseX::Types有这方面的细节信息。

不变性

一个精心设计的对象，你只需要告诉它该做什么，而不是怎么去做。如果你发现自己需要从对象之外接触内部数据（即使是通过访问器、设置器），就要意识到可能封装得不够。

你可以让对象不可改变，来阻止这种不恰当的接触。在构造方法中提供必要的数据，然后阻止一切来自外部的修改。一旦你构建了这样的对象，你就知道它总是有效的，因为你无法修改它的数据让它变到无效的状态。

这需要很强的自律，但是由此产生的系统是可靠的、可测试、可维护的。有些设计甚至还尽可能禁止内部修改，当然这更难实现。