我一直在为从一段时间以来一直从事 Java 工作的参与者提供有关编程实践和编写质量代码的培训。面向对象的分析和设计是基础，我涵盖了 S.O.L.I.D.原理和摘自 Clean Code、Code Complete 2 等书籍。
我计划在两天内为 Perl 程序员（不到 1 年的 Perl 经验）提供培训，他们不使用 Moose（Perl 5 对象系统的扩展，它带来了现代面向对象语言功能）。
我现在对如何组织我的培训感到困惑，因为他们不遵循 OOP。
有什么建议吗？
问候， 沙杜尔。
【问题讨论】：
标签： perl
即使没有 Moose，Perl 中的面向对象编程也很有可能，而且非常普遍。许多 CPAN 模块通过面向对象的 API 提供其功能，即使其中许多也提供非面向对象的 API。 （这种二元性的一个很好的例子是IO::Compress::Zip。）显然，Perl 中的面向对象设计规范与某些语言中的规范有些不同——例如，语言不强制执行封装——但总体原则和实践是一样的。
即使没有任何类型的面向对象编程，无论是 Mooish 还是其他，在布局包、将代码组织成函数/子例程/模块、结构化数据、利用 use warnings（或-w) 和 use strict 和 -T 和 CPAN 模块，等等。
我还推荐 Mark Jason Dominus 的书 Higher-Order Perl，他已提供免费下载。我不知道你能在多大程度上在一天之内完成整本书，并及时整理出一些有用的东西来进行演示——函数式编程对于不习惯它的人来说是一种范式转换（无论是你，或者你要介绍的程序员！）——但你可能会在那里找到一些有用的东西，你可以使用。
【讨论】：
这里的很多答案都是关于向不使用它的 Perl 程序员教授 OOP 的答案，但是您的问题听起来像是您在如何教授代码质量课程方面受到阻碍，因为您的Perl 程序员不使用 OOP，并不是说你想向非 OO 程序员教授 OOP 并强迫他们进入那种范式。
这给我们留下了 Perl 很好地支持的另外两种编程范式：
我同时使用这两种方法——也结合了健康剂量的物体。因此，我使用对象的原因与我使用良好的结构和模块以及功能管道的原因相同。使用为编程过程带来秩序和理智的工具。例如，面向对象编程是多态的主要形式——但 OOP 本身并不是多态。因此，如果您正在编写有助于多态性的惯用语，它们有助于多态性，它们不必被困在某个临时库“类”中，并且像 UtilClass->meta_operator( $object ) 这样调用，它具有little 多态性本身。
Moose 是一种伟大的 对象语言，但你不调用Moose->has( attribute => is => 'rw', isa => 'object' )。你打电话给操作员has。 Moose 的力量在于一个对象库，它封装了对类的元操作——但也在于 Perl 相当开放的语法允许的简单表达运算符.我称之为对解决 OOP 用对象解决的问题的欣赏。
另外，我想我对您的问题有疑问，因为“非 OOP”是一个很大的领域。它的范围可以从主线中的所有内容编码到非-严格-OOP（编程的过程不仅仅是OOP分析）。所以我认为你必须了解你的听众，知道他们用什么来保持代码的结构和健全。我无法想象一个现代 Perl 观众至少不是对象-用户。
从那里，Perl Best Practices（通常缩写为 PBP）可以为您提供帮助。但是学习也是如此
此外，作为对象作者和消费者，OOP 不是我认为的方式。 可重用性是我思考的方式：之前我做了什么我不想再写了？我写了哪些类似的东西？我怎样才能使我当前的任务只是以前编写的内容的适配器。 （而且经常：我怎样才能在一行中偷偷将我的行为分支一个已建立的模块？）
因此，我的一些构造将失败 OOP 的普通目标。为了让您更好地了解：我将代码分为两个“域”：高度抽象和多态的 Library 代码，以及我需要做的 Scripting 以获得 特殊功能。 （这本质上是“应用程序”的意思，但我不认为它会那么清楚）。因此，多态性主要有助于提供适应性，但适应性本身就是需要最少的代码行数。我的最佳系统将是一个库，它允许在库行为和解决特定问题的一组配置或脚本之间的任何接合处进行脚本/适应。同样，如果我有我的 druthers，配置将从脚本域注入，并且没有库代码本身会说“我需要一个属性文件”，除非它是一个库模块，它封装了属性文件中实例化的配置算法。它只会知道它需要“策略”（或来自应用程序域的决策）来实现其功能。
因此，我的理想应用程序包含特殊用途的“对象”，它们符合“角色”，但其中 类 是无用的开销——除了类执行允许可注入数据和行为的行为。所以我的一些 Perl “对象”违反了 OOP 分析，因为它们只是一次性解决方案的封装，有点像图钉（扩展）JavaScript 对象。
当我发现我需要再次编写类似的东西时，我会经常（稍后）修改一个特殊用途的对象并将其进一步推回库域。库域中的所有对象都只是特定行为范围的某个级别。此外，我安排了“数据网络”，其中有一个 Sourced 类型的类，它简单地封装了在对象本身或另一个源对象中访问数据的行为。这有助于加快我的解决方案非常，但我从未在任何鸭-猫-狗-汽车-卡车 OOP 入门手册中看到它。此外，模板——尤其是与“数据网络”结合使用时——在六行或半天的工作中对解决方案进行编码非常有用。
所以我想我是说，就你只知道用于结构化编程的 OOP 而言，你将无法理解一些较旧的、合理的实践或其他范式对你——或符合 OOP 条件的事物如何促进平庸的适应性。 （除了 组件 比“对象”更流行。）封装解决了许多问题，但它也促进了您需要的数据的缺乏。这个想法是在您需要的地方获取数据，以便您的固定行为可以实现问题的细节并对其进行操作。
还有可能即使是一个成熟的、“富有成效的”Perl 团队也在编写……废话。如果他们不是 OOP 程序员，因为他们只是在编写垃圾代码，那么一定要教他们 OOP，如果他们甚至缺乏结构化编程 *把他们两个都逼到喉咙里*（我很难过考虑到标签“专业”，这里）。
【讨论】：
好好看看 Damian Conway 的 'Perl Best Practices'。里面有很多扎实的材料，听他的建议你不会错的。
但请注意，Getopt::Clade 仅作为占位符包提供 - 换句话说，它是 vapourware。
【讨论】：
您可能还想看看“Modern Perl”一书中所涵盖的内容：
http://onyxneon.com/books/modern_perl/
正如其他人所说 - 没有 Moose 有很多内容。
【讨论】：
Perl 程序员必须了解 Perl 的弱功能特性，如列表上下文、映射、grep 等。一点点功能风格使 Perl 的可读性无限提高。
Perl 程序员还必须了解 Perl 的传统 OO 特性，尤其是模块、bless 和 tie。让他们写一个对象，或者将一个 Cache::Memcached 对象与查询或其他东西联系起来。
【讨论】：