Abh*_*hek 5 php oop software-design
我想知道为什么我们在php中使用类.我在所有开源中看到他们使用类来执行查询.这意味着他们使用类来获取结果,插入查询等.我认为这用于一致性和加速,但据我所知,如果我们执行查询使用mysql_query(),而不是创建一个对象链接$db->query将执行快速与第二个相比,因为在对象中它将转到该函数,然后在那里执行它,之后它返回结果但是如果mysql_query()它将在同一个地方执行查询.所以我认为mysql_query()会快速执行.那么为什么我们使用类和对象来执行查询,使用类有什么好处？
Sed*_*glu 12
封装:类是一个有用的数据包,包含代码和相关数据,与其他所有内容隔离.这使得在不搜索精确变量的情况下更容易移动它,而不会与现有代码/数据发生冲突.
当然类有其他用途,但在像PHP这样的脚本环境中,我认为最大的优点是.
编辑:我反对"继承比封装更强大"的论点.我认为这不适用于脚本和Web场景,我会尝试解释原因:
首先,网页的生命周期是请求/响应对,理想情况下不到一秒.状态通常保存在外部实体(会话,cookie,db等)中.由于页面的生命周期非常短,因此网页代码中的可能状态比胖客户端少.几乎总是小的代码运行并持续完成工作.可以说,在简单性和设计参数数量方面,网页与控制台应用程序相当.尽管输入参数的数量可以是表格中的千兆字节,但是UI元素和输入参数之间的关系限于屏幕分辨率,用户对他/她可以立即填写的内容的总体能力.因此,在大多数情况下,我们输入参数的数量很少,这意味着状态数量较少.当然,在组合和"可变"的世界中,这不是真的,但在"典型的网络应用"的情况下,内部状态也很小,因此使我的主张变得合情合理.
Web应用程序中的输入和输出大致相同:输入是查询参数或表单数据,输出是HTML文档.因此,在其短暂的生命周期中,输入处理和输出生产代码的形状类似并且设计用于网页.我知道我在图片中省略了一大块"业务逻辑",我会明白这一点.但是,让我们确保在代码的这些部分中没有使用OOP的漂亮功能,如"多态"和"继承".有很多已知的,长期研究的,实用的和非OOP模式.使用"多态","访问者模式"等发明解析查询参数的新方法至少是愚蠢的.
数据访问也由现有的库执行,诸如"继承"或"多态"之类的奢侈品在那里没有用.您仍然可以使用类,但这只是封装.您不能继承/重用MySQL代码来编写T-SQL或PL/SQL代码.你需要一个完整的替代品.哦,也许你SELECT * FROM table可以"继承",想想可能性,哇.
现在我们离开了什么？是的,业务逻辑.我们已经提到业务逻辑也是信息处理的短暂爆发.PHP代码本身没有持久的业务状态.我们知道,由于Web的要求,几乎所有的业务运营都必须不到一秒钟.因此,您可以再次通过的状态远远少于完整的应用程序.在典型的Web应用程序中,大多数情况下都会进行原子的,孤立的业务操作.
现在让我们回到设计.我们知道我们的页面包含以下部分:
我们已经获得了多态和继承范围之外的输入,数据和输出.这是我们的最终图片:
虽然业务逻辑可能是我们应用程序的最大部分,但它仍然必须在我们的Web应用程序的第二个窗口中,因此必须很小,也就是短暂的.
是的,超级计算机可以在一秒钟内做很多事情,但我们仍然在谈论大多数常见情况.有什么共同之处？CRUD很常见.这就是为什么Ruby on Rails和Active Record模式如此成功并获得如此受欢迎的原因,因为它提高了一件事的生产力:CRUD.
设计的复杂性与所涉及的数据元素和操作的数量成比例.而且由于我们假设大多数操作都是CRUD,我们有固定数量的操作和少量的输入参数,我们有一个小问题空间.
可能存在例外情况,但对于大多数情况,小问题空间的设计不能同时复杂和良好.除非有大量的数据点和过多的冗余,否则你不太可能在网页的设计中使用继承.我再说一遍,对于大多数情况来说,这是原始的CRUD.
第二,(是的,如果您忘记了,开头会有第一个),Web应用程序性能很重要(如果不是关键) - 记住"一秒钟" - 在脚本环境中,它的重要性是其两倍.
面向对象的范例依赖于一个非常重要的低级机制,它同时具有有用性和高性能:指针间接.CPU读取指针并跳转到其指向的地址的能力与直接跳转到地址几乎没有区别.这样我们可以有一个虚方法表用于查找正确的函数调用,这样编译器可以调用对象的"some()"方法,而不知道它的确切类型,因为它只是指针中的任何东西,但它仍然像疯马.
这个梦想终结于脚本世界.您没有本机执行CPU的指令.您有PHP编译器生成的字节码,由PHP解释器解释.与CPU不同,PHP解释器必须处理更高级别的概念,如抽象,类,类型,而不管它是字节码.CPU的简单指针间接是PHP的一组复杂操作.解析操作,理解操作,可能进行一些健全性检查,最后用另一组字节码执行它.
因此,脚本世界中继承的开销是比本机环境慢的数量级.
当然,只要收益超过损失,这是可以接受的.并且考虑到性能损失可以通过升级,集群等其他方式恢复,这似乎不是问题.这当然是真的,这是我最后的陈述:
对于Web应用程序开发中的大多数场景,可以在不调用继承/多态的情况下实现同样可维护,同样可重用且可能更高性能的设计,因此封装是PHP中最常见和最大的好处,而不是继承.