我一直在为从事Java工作的参与者提供有关编程实践和编写质量代码的培训.面向对象的分析和设计是基础,我涵盖了SOLID原则和摘自清洁代码,代码完成2等书籍.
我计划在两天内向Perl程序员(在Perl中使用不到1年的exp)提供培训,他们不使用Moose(Perl 5对象系统的扩展,它带来了现代的面向对象语言功能).
我现在很困惑如何构建我的训练,因为他们不遵循OOP.
有什么建议？
此致,Shardul.
rua*_*akh 12
即使没有Moose,Perl中的面向对象编程也是非常有可能的,而且很常见.许多CPAN模块通过面向对象的API提供其功能,即使其中许多也提供非面向对象的API.(这种二元性的一个很好的例子是IO :: Compress :: Zip.)显然,Perl中面向对象设计的规范与某些语言中的规范略有不同 - 例如,封装不是由语言强制执行的 - 而是整体原则和做法是一样的.
即使没有任何形式的面向对象编程,Moosish或其他,在布局包,将代码组织到函数/子例程/模块,构造数据,利用use warnings(或-w)use strict和-T和CPAN模块方面都有很多可以谈论的内容., 等等.
我还推荐Mark Jason Dominus的书High-Order Perl,他已经提供免费下载.我不知道你能在多大程度上在一天之内完成整本书的比赛,并在你的演讲中及时整理一些有用的东西 - 函数式编程对于那些不习惯它的人来说是一种范式转换(不管你吧,或者你正在展示的程序员!) - 但是你可以在那里找到一些有用的东西,你可以使用它们.
这里的很多答案都是关于向没有使用它的Perl程序员教授OOP的答案,但是你的问题听起来像是因为你的Perl程序员做的事情,你在如何教授代码质量的课程上受到了阻碍不要使用OOP,特别是你不想向非OO程序员教授OOP并强迫他们进入这种范式.
这让我们得到了Perl支持的另外两种编程范例:
我同时使用这两种方法 - 结合健康剂量的物体.因此,我使用对象的原因与我使用良好的结构,模块和功能管道的原因相同.使用为编程过程带来顺序和理智的工具.例如,面向对象编程是多态的主要形式 - 但OOP 本身不是多态.因此,如果你正在写的是协助多态性成语,他们在协助多态性,他们没有被卡在一些特设库"类",并呼吁像UtilClass->meta_operator( $object )其中有一点多态性本身.
Moose是一种很棒的对象语言,但你不要打电话Moose->has( attribute => is => 'rw', isa => 'object' ).你打电话给接线员 has.该电源的Moose谎言在库对象封装在类元操作-而且在简单的表现运营商是Perl的相当开放语法允许.我想称解决OOP解决问题的对象.
此外,我想我的问题有问题,因为"不是OOP"是一个很大的领域.它可以包括从主线编码到非严格 -OOP(编程过程不仅仅是OOP分析).因此,我认为您必须了解您的受众,并了解他们使用什么来保持代码的结构和理智.我无法想象现代的 Perl观众至少不是对象用户.
从那里,Perl Best Practices(通常缩写为PBP)可以帮助您.但是那样学习
另外,与我的对象作者和消费者一样大,OOP 不是我想的那样.可重用性是我的想法:在我不想再写之前我做了什么？我写的是什么类似的？如何使我当前的任务只是以前编写的适配器.(而且经常:我如何偷偷摸摸我的行为在一条线上分支一个已建立的模块？)
结果,我的一些构造将失败 OOP的行人目标.为了给你一个更好的观点:我将代码划分为两个"域":高度抽象和多态的库代码,以及我需要做的脚本来获得当前项目中我需要的特定函数.(这基本上就是"应用程序"的意思,但我认为它不会那么清楚).因此,多态性主要有助于提供适应性,但适应本身就是采用最少代码行的任何东西.我的最佳系统是一个库,它允许在库行为和解决特定问题的一组配置或脚本之间的任何关键时刻编写/调整脚本.同样,如果我有我的druthers,配置将从脚本域注入,并且没有库代码会自己说"我需要一个属性文件",除非它是一个库模块封装了属性文件中的实例配置算法.它只是知道它需要"策略"(或来自应用程序域的决策)才能实现其功能.
因此,我的理想应用程序包含特殊用途的"对象",它符合"角色"但是类无用的开销 - 除了类执行允许可注入数据和行为的行为.因此,我的一些Perl"对象"违反了OOP分析,因为它们只是一次性解决方案的封装,有点像push-pin(expando)JavaScript对象.
我经常(稍后)修改一个特殊用途的对象并将其进一步推回到库域中,因为我发现我需要再次写这样的东西.库域中的所有对象仅处于指定行为的某个级别.此外,我安排了"数据网络",其中有一种Sourced类简单地封装了在对象本身或另一个源对象中访问数据的行为.这有助于极大地加速我的解决方案,但我从未在任何鸭 - 猫 - 狗 - 卡车OOP底漆中看到它.同样模板化 -特别是与"数据网络"结合使用时 - 在半打或半天工作中编码解决方案非常有用.
所以我想我说的是,在某种程度上你只知道OOP用于构造编程,你将无法理解一些旧的,合理的实践或其他范例为你做的事情 - 或者那些有资格作为OOP的事情可以促进平庸的适应性.(除了组件远比"对象"更新.)封装解决了许多问题,但它也促进了您需要的数据缺乏.我们的想法是在您需要的地方获取数据,以便您的固定行为能够实现问题的具体细节并对其进行操作.
即便是一个既定的,"富有成效"的Perl团队也可能正在编写...... 废话.如果他们不是OOP程序员,因为他们只是编写垃圾代码,那么无论如何教他们OOP,如果他们甚至缺乏结构化编程*将他们两个都推到他们的喉咙*(我很难考虑标签"专业",这里).