Perl OO框架和程序设计 - Moose和Conway的由内而外的对象(Class :: Std)

Emm*_*mel 9 oop perl class moose

这更像是一个用例类型的问题......但也足够通用,可以更广泛地应用:

简而言之,我正在研究一个或多或少是命令行包装器的模块; OO自然而然.没有太多细节(除非有人想要它们),系统没有疯狂的复杂程度,但在这个框架中有三到四个对象确实很自然.最后,它是一个开源的东西,我将放在那里,而不是一个模块与同一公司的一些开发人员一起工作.

首先,我使用Class :: Std实现了OO,因为Perl Best Practices(Conway,2005)为什么要使用由内到外的对象做出了很好的论据.完全控制访问哪些属性等等,适当的封装等.此外,他的设计非常简单和聪明.

我喜欢它,但后来注意到没有人真正使用它; 事实上,康威自己似乎不再推荐这个了吗?

所以我感动了每个人的最爱,穆斯.它很容易使用,虽然方式过度杀戮功能明智的我想做什么.主要的重大缺点是:它有一大堆模块依赖,迫使我的模块用户全部下载.一个小小的缺点是它的功能比我真正需要的更多.

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

对于适当的Perl OO框架是否有第三种选择,这种框架很受欢迎,但这两种框架都没有?

Ken*_*ric 5

为了完全公平,在Perl世界中看到几乎所有有趣的东西都将Moose作为依赖,我不认为这对其他"Perl开发者"来说是一个很大的负担.

他们说话的时候他们已经安装好了!

编辑:一些统计数据:

Moose目前在"最依赖"模块列表中排名第65位,别名排名前100位,超过1637个包依赖于它.这几乎Time::HiRes和其他东西一样多DBI,而且我不认为你会根据那些问题提出质疑?


Eth*_*her 5

目前接受的"现代Perl OO框架"是Moose.我会说让你的用户下载它,或者你可以使用PAR :: Packer将它与你的模块捆绑在一起.

引自" 但我不能使用CPAN "(...因为我的用户不想安装东西):

假设您只是在处理用户tarball,那么Module :: Install提供了一个解决方案 - 如果您将脚本放入脚本/然后执行

install_script(glob 'script/*');
auto_install;
Run Code Online (Sandbox Code Playgroud)

在你的Makefile.PL中,不仅'make install'将你的脚本放在适合你的地方,但'make installdeps'会调用cpan(或者如果存在,cpanplus)来为你安装所有缺少的依赖项.


cjm*_*cjm 4

嗯,有Mouse,它类似于Moose但没有所有依赖项(以及一些功能)。它的启动速度也更快一些。我自己没有尝试过,但总体来说这是很好的想法

  • 不,不要这样做。切勿使用 Any::Moose。 (4认同)
  • 驼鹿很棒。使用驼鹿代替鼠标。# “描述”下的第 1 行 (2认同)