使用 CGI.pm 和 Perl 的两种不同编程风格有何优缺点？
我正在学校上 Web 脚本课程，正在完成我的第一个作业。我倾向于做得太过分，并且对我的学科钻研得比课堂上要求的更深入。现在我正在研究 CGI.pm 来执行我的 HTTP 请求，它说 CGI.pm 有两种编程风格：
- 面向对象的风格
- 面向函数的风格
除非我忽略了明确的答案，或者知识不足以辨别从以下位置提供的文档中为自己解答： http://perldoc.perl.org/CGI.html 我只是不知道使用这两种不同风格的优点和缺点是什么。
话虽如此，使用两种不同风格的优点和缺点是什么？哪一种比较常用？至于使用面向对象的风格，它说我一次只能使用一个 CGI 对象。这是为什么？
感谢您的帮助。你们让我学习计算机科学变得非常愉快、满足和有益。 =D
I am in a Web Scripting class at school and am working on my first assignment. I tend to overdo things and delve deeper into my subject than what is required in my classes. Right now I am researching CGI.pm to do my HTTP requests and it says there are two programming styles for CGI.pm:
- An object-oriented style
- A function-oriented style
Unless I overlooked the clear answer or am not knowledgeable enough to discern the answer for myself from the documentation provided at: http://perldoc.perl.org/CGI.html I just don't know what the pros and cons are of using these two different styles.
With that being said what are the pros and cons of using the two different styles? Which one is more commonly used? As far as using object-oriented style it says I can only use one CGI object at the time. Why is that?
Thanks for all your help. You have all made studying Computer Science very enjoyable, satisfying, and rewarding for me. =D
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在幕后，CGI.pm 正在做同样的事情，尽管风格不同。函数式接口实际上使用了一个你看不到的秘密对象。
对于许多小型 CGI 项目，您可能永远不会一次需要多个 CGI 对象，因此函数式接口就很好。这可能是更常见的风格，但这只是因为大多数人为非常具体的任务制作小脚本。如果您还有很多其他事情要做，您可能不喜欢 CGI.pm 将一长串（而且很长）函数名称导入您的脚本中。某些函数名称可能与要导入的其他模块发生冲突。
然而，我总是使用面向对象的接口。我不必担心名称冲突，而且自从您看到它的对象以来，任何方法的来源都很明显。将对象作为参数传递给大型应用程序的其他部分也很容易，等等。
有些人可能会抱怨额外的打字，但这对我来说从来都不是编程的缓慢部分。我已经使用 Perl 很长时间了，而且我不介意语法。然而，我只使用 CGI 来获取输入，也许还发送输出。我不会搞乱任何 HTML 内容。
当它一次谈论一个 CGI.pm 对象时，它指的是对输入的访问。例如，一旦您读取了 STDIN，另一个 CGI.pm 对象将无法读取它。不过，您可以拥有任意数量的对象。他们只是不会共享数据，第一个获得所有 POST 数据。
但实际上您可以使用混合物。您可以导入一些内容，例如
:html，但仍然使用 OO 接口来处理输入。Behind the scenes, CGI.pm is doing the same thing despite the styles. The functional interface actually uses a secret object that you don't see.
For many small-scale CGI projects, you're probably never going to need more than one CGI object at a time, so the functional interface is fine. This might be the more common style, but only because most people make small scripts for very specific tasks. If you have a lot of other stuff going on, you might not like CGI.pm importing a long list (and it is long) of function names into your script. Some of the function names might clash with those other modules want to import.
I, however, always use the object-oriented interface. I don't have to worry about name collisions, and it's apparent where any method came from since you see its object. It's also easy to pass the object as arguments to other parts of large applications, etc.
Some people might complain about the extra typing, but that's never been the slow part of programming for me. I've been doing Perl for a long time and I don't mind the syntax. However, I only use CGI to get the input and maybe send the output. I don't mess with any of the HTML stuff.
When it talks about one CGI.pm object at a time, it's referring to access to the input. Once you've read STDIN, for instance, another CGI.pm object won't be able to read that. You can have as many objects as you like though. They just won't share data and the first one gets all of POST data.
You can actually use a mixture though. You can import some things, like
:html, but still use the OO interface to deal with the input.我强烈建议使用对象接口。
你的课堂作业绝对需要它吗？不，事实上，即使对于小型生产项目来说，这也可以说是过度杀伤力。
然而，如果您认真学习使用 CGI.pm 进行大型项目，您将需要学习对象方法。如果您需要两个对象，则必须使用对象接口。与大多数其他事情一样，编程可以通过练习变得更好。现在练习相对简单的问题将帮助您为更复杂的问题做好准备。
事实上，我建议将其作为编程中的一般规则（尽管也有例外），即如果面临使用特定工具的两种方法，请养成使用最有可能在生产代码中使用的方法和/或方法的习惯这是更多问题空间的正确答案。
I strongly recommend using the object interface.
Will it be absolutely required for your classwork? No, in fact it is arguably overkill for even small production projects.
However, if you are serious about learning to use CGI.pm for larger scale projects you will need to learn the object method. If you reach the point of needing two objects you will have to use the object interface. Programming, like most everything else, gets better with practice. Practicing now on relatively easier problems will help you be ready for more complex ones.
In fact I'd recommend it as a general rule in programming (although there are exceptions) that if faced with two methods of using a particular tool making a habit of using the one most likely to be used in production code and/or the one that is the correct answer for more of the problem space.