OO代码在典型Web应用程序上下文中的优缺点

时间:2014-03-06 22:06:46

标签: php oop web-applications

我很想知道使用OOP范例而不是过程开发Web应用程序的优缺点。

感兴趣
  • OOP vs Procedural
  • 除典型Web应用程序之外的上下文,表示客户端向服务器发出HTTP请求的分布式应用程序

我的问题是因为我一直在开发一个在我公司的Intranet上运行的Web应用程序这一事实,并且希望这个应用程序能够被最终取代我的人“轻松”维护,以便应用程序留下来并没有取代一些过度抽象的过度设计的付费解决方案,很少有人会喜欢与之合作。

我在codereview上发布some bits of my application source进行审核,但我没有得到很多反馈。然后我在reddit / r / PHP上发布了a link到我的帖子上的codereview,但是并不是很好。

目前,我的印象是绝大多数“网络开发”社区已经决定OO是要走的路。我很难理解为什么,但我觉得我的公司下一代开发人员也会坚定地相信为网络应用程序开发OO,因为它现在似乎是常态。

我想同意他们并加入这个行列,有人可以尝试向我解释OOP在Web应用程序的典型环境中的优缺点。

在进行一些研究时,我遇到了really interesting commentthis one too,这让我更难以进行转换。

其中一条评论的小引用:

  

OOP适用于无法正确设计软件的人员,也适用于参与非常大型或复杂的非Web项目的合格程序员。如果我要编写一个在PC上运行的事件驱动游戏,我不会选择程序编程。

2 个答案:

答案 0 :(得分:0)

现在很多Web应用程序框架的卖点是它是一个MVC框架。您拥有与View和Model接口的Controller。该模型是您的业务和数据层,其中包含业务对象/实体/数据对象 - 基本上是使用消息相互通信的对象。对象本身仅限于它所独有的内容以及它可以做的事情。

这些边界/限制在某种程度上使其他人更容易理解您的代码以及如何修改它。它还有助于单独测试这些层中的每一层。

我想如果你想要快速开发的应用程序,控制器查询数据库并向视图发送信息,你也可以这样做。但测试的唯一方法是运行应用程序,检查是否有问题,修复,重启,再次测试..你不会节省很多时间。

修改

您正在使用具有业务逻辑的单个控制器。但是你的模型看起来非常像OO模型应该是什么。所以我要问的问题是,如果我将此控制器分解为特定于域,会发生什么?然后我必须创建一个UserController和一个DepartmentController,UserController呈现与CRUDing用户相关的所有视图。这值得吗?绝对。无论您的应用程序需要什么,其他人都可以跳入并使用AdminController或ReportingController,而无需担心您对此控制器所做的更改。

如果你们其中一位同事希望看到部门部门做了一些改动,你就不用担心其余的了。

答案 1 :(得分:0)

首先,我根本不是一个Php人,但你的自我赞美问题似乎很有趣,所以我研究了一下。我的回答是通用的,与面向对象技术或Web技术的特定实现无关。

对象将数据与相关功能一起封装在一个整体中。并不是说你将整个应用程序封装在一个巨大的对象中。很多与你如何分析问题,识别对象和使用它们有关。

作为请求 - 响应事物的Web应用程序在90年代早期可能是正确的,但现在Web应用程序已经成熟。没有必要遵循典型的请求 - 响应方案。你看过股票追踪应用了吗?它不会等待发送响应的请求。只要数据可用,它就会发送。我参与了在线候选测试网络应用程序,该应用程序在固定的时间内询问问题。一旦时间到了,它就会结束测试用户是否“请求”结束它并显示结果。即使它关闭了用户机器或存在网络问题,它也会记住并且再也没有问过同样的问题,也没有给出额外的时间。

是的,有不好的程序员或“ IT-guys ”完全没有意识到 OO-analysis 。他们以一种非常程序化的方式对物体进行编程。他们的工作成果是一个请求 - 响应风格的Web应用程序,包含3个全局变量'z'命名空间,但这并不意味着应该归咎于OO范式本身。它适用于那些不太了解它的人,因为它适用于正确的地方!