由于几乎所有模块都有，并且反复说我们不应该重新发明轮子，因为我不为CPAN编写模块，所以我不需要使用OO。 但我的问题是，专业的Perl代码主要是用OO风格编写的吗？
答案 0 :(得分：8)
简而言之，只有你想要代码可重用性和可读性;为了编写简单的系统脚本或代码来执行一项任务，那么这是一种浪费，特别是如果它是那种不能很好地记录的东西。例如，在编写复杂程序时，通过编写一系列好的模块来组织一个人的想法并模块化问题确实很有帮助。在处理具有多个开发人员的项目时，使用面向对象的好处会呈指数级增长。
答案 1 :(得分：5)
我认为OOP主要是将行为绑定到数据结构的一种方式。每当我的数据结构看起来变得复杂时，我就会组合对象。
这有助于集中和抽象与操作数据相关的代码。这反过来减少了重复的代码并简化了重构。使用纯粹的程序代码可以实现相同的目的。我发现OOP使关系更直观，更容易以直观的方式进行概念化。
考虑这个结构：
my $foo = {
meezle => [qw( a d g e l z )],
twill => {
prat => 'qua',
nolk => 'roo',
},
chaw => 7,
mubb => [ 123, 423,756, 432 ],
ertet => 'geflet',
};
当我结束这样的结构（嵌套和非均匀）时，我开始思考“对象”。当我发现自己编写大量代码来访问，修改和验证结构中的数据时，我确信。
由于大多数非平凡的项目需要非平凡的数据操作，因此我至少在大多数工作的某些部分使用对象。
我可能会也可能不会在我的OOP中全力以赴。通常有一些东西不是对象。可能有也可能没有应用程序基类。某些元素可以作为普通过程代码处理。一些可能包括功能方法。这完全取决于考虑到项目要求的意义。
最重要的是要记住，你的代码必须对负责维护它的穷人是明确的。 （这可能是你在6个月内，从凌晨4点开始新近醒来，睡觉，老板的老板的老板尖叫着你在公司破产之前修复该死的软件。）
答案 2 :(得分：3)
我编写的大多数Perl代码都是小型脚本，我从不使用OOP，即使它们使用的是OOP设计的CPAN模块。对于较大的代码项目，我倾向于OOP大约70％的时间，但它取决于：代码将被使用很长一段时间？如果它可能会留下来并且许多用户将他们的勺子浸入混合物中，OOP可能是更好的设计。
答案 3 :(得分：2)
OO-design simply had a better marketing group
这恰好源于人们认为“大多数代码”应该是OO的事实。当然，你可以跟踪“内部在一个对象中”的状态，但它也会让人们在对象内部做一些愚蠢的事情，使事情变得更加复杂。
我的问题是“大多数用OO编写的代码”。我相信物体和功能之间应该有一个健康的平衡。函数可以在Objects上运行。
有很多东西不能很好地适用于物体。
答案 4 :(得分：1)
如果您正在编写一个简单的脚本来执行一些相对简单的处理，文件修改等，那么可以使用非OO设计，但根据我的经验，如果您的脚本将会更长时间并且可能会执行您的操作也许有一天可能想要在另一个脚本或不同的环境中重复使用，而不是你最好采用面向对象方法的计划。总的来说，它也更容易扩展和增强基于面向对象的设计。
特别是在表示任何类型的数据时。一旦编写了表示该数据的类，就可以非常方便地向该数据类添加有用的方法（例如显示，检查，分析，重置，写入文件，从文件加载等）。
这也有一个积极的副作用，使你的脚本更简洁，易于阅读和维护，因为对数据的许多操作细节都留给了类方法。如果你正在处理大量的数据，那么处理对象数组也会更容易，而不是使用哈希，如果你没有OO设计，你可能会最终使用它们。
将来如果您必须编写脚本以不同的方式处理相同的数据，您可以简单地在不同的脚本中重用数据类。如果您的数据恰好有所不同，那么您需要添加更多字段或更多方法。没问题，只需扩展原始数据类。
我发现的学习OO Perl的最佳参考是：面向对象的Perl：Damian Conway的概念和编程技术综合指南。当我开始做OO Perl时，我遇到的一件事就是有很多不同的方法可以做到这一点。最后，我刚刚决定使用它，多年来一直坚持使用它。