Perl OO框架和程序设计 – Moose和Conway的内向外对象(Class ::

发布时间：2020-12-15 22:03:55 所属栏目：大数据来源：网络整理

导读：这更多是一种用例类型的问题,但也足够普遍适用：简而言之,我正在使用一个或多或少的命令行包装器的模块; OO自然.没有进入太多的细节(除非有人想要它们),系统的复杂性并不复杂,但在这个框架中有三到四个对象确实感到自然.最后,这是一个开源的东西,我会把它放

这更多是一种用例类型的问题,但也足够普遍适用：

简而言之,我正在使用一个或多或少的命令行包装器的模块; OO自然.没有进入太多的细节(除非有人想要它们),系统的复杂性并不复杂,但在这个框架中有三到四个对象确实感到自然.最后,这是一个开源的东西,我会把它放在那里,而不是在同一家公司工作的一些开发人员的模块.

首先,我使用Class :: Std实现了OO,因为Perl最佳实践(Conway,2005)为为什么使用内向外对象做了一个很好的论证.完全控制什么属性访问等等,适当的封装等.此外,他的设计是惊人的简单和聪明.

我喜欢它,但后来注意到没有人真的使用这个;其实呢似乎康威自己也不会真的推荐这个了？

所以我转到大家的最爱,麋鹿.它很容易使用,虽然方式overkill功能明智我想做什么.大的主要缺点是：它有一些模块依赖,迫使我的模块的用户下载它们.它的一个小缺点是有更多的功能比我真正需要的方式.

什么是建议？不方便的开发人员迫使他们使用可能过时的模块,或强制模块的每个用户下载Moose及其所有依赖项？

是否有适合Perl OO框架的第三个选项是受欢迎的,但这两个框架都不是？

为了完美公平地看,几乎所有有趣的事情Perl世界中有一些Moose在某个地方作为一个依赖,我不认为这是其他“Perl开发人员”的债务.

有可能他们已经安装了,因为我们说话！

编辑：一些统计：

目前,Moose在“最依赖”模块列表(Aliases top 100)中排名第65位,其中包含超过1637个软件包.这几乎和Time :: HiRes这样的东西一样多,而不是DBI,而且我不认为你有可能根据你的想法来提问吗？

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!