可能重复:
类.重点是什么？
我已经阅读了大量的教程,写了许多课程,使用过它们,但我仍然无法弄清楚一些OOP点.
我的意思是,我认为我得到了理论.这是一种范式,一种思考和解决问题的不同方式.我知道所有的共同点:代码重用,封装,更好的错误处理,更容易的维护,继承,合同设计,更好的文档,聚合,组合,一些设计模式......
那就是说,让我们去做真正的交易吧.假设我有以下内容:
所有这一切都很棒,确实很有用但是...我不能停止思考最简单的情况:列出一些人.是的,因为输出表上的每一行都是在一个类实例上创建的.我无法停止思考在未使用的资源上使用了多少内存和CPU.
清单50人意味着创建50个实例,充满了诸如crud,过滤处理上传,验证规则等资源,当我需要的是运行查询并只用简单的循环输出结果时.
这让我很困惑.而且不仅仅是混淆,因为我已经看到了一些应用程序,当业务规则稍微复杂时,运行时会随着数据库的增加而逐渐增加.
我认为,是创建新类或普通脚本来处理输出和报告的情况？如果是,那么这意味着双重努力,使用OOP毫无意义,一旦我需要为同一个数据库实体创建许多不同的类.编码变得更难,维护变得不酷.
我错过了什么吗？或者这是OOP方法的缺点？
我们是否应该直接牺牲一点,更薄,更快的代码以便更快地开发和维护？
编辑
正如所料,我之前提出的一些观点对某些人来说是误导......
首先,我经历了真正非常大的项目(我曾在IBM为Sprint/Nextel USA和Directv North America工作,因此我习惯于看到每天处理一些太字节).
当我说从数据库中检索到50个人时,我并不是指50个人,我只想提出许多记录的想法.我知道50条记录对于今天的服务器来说并不算什么.5000万是.如果合适,想象一下这最后一个数字.
正如你所说,这是一种范式.它有任何其他范式的优点和缺点.我认为你错了的地方是什么具有重大意义.是什么让50个实例成为一个大数字？或许对你来说,跟踪50个谨慎的东西是很困难的(对所有人来说都是如此),但这并不意味着它对计算机来说很难.那个50并不大,只因为它对你来说似乎很大.与用于检索数据和整理结果的简单脚本示例相比,这肯定很大,但权衡应该是显而易见的,当您指出OOP的优势时,您列出了大部分内容.更有趣的一点是,当这些优势超过弱点时.与你在此处发现的内容相比,判断调用还要多得多,包括代码库的大小,涉及的开发人员数量,彼此之间的相对技能,代码将在生产中保留多长时间等等.
这是问题的症结所在.如前所述,每个范例都存在权衡.OOP有很多好处,但是你指出它也有一些负面影响.关键是权衡它们.
OOP建立在开发人员昂贵且硬件便宜的原则之上.它使用此主体来实现高度可维护性(从长远来看易于修复)和高适应性代码(从长远来看易于更改).如果您购买60/60规则(其中60%的开发时间用于维护,60%的时间用于增强),那么可维护性是专业编程的最终目标.
如果你了解OOP是如何工作的(我正在谈论你在OOP范式中的思考点),一切都变得非常简单.我认为你仍然感到困惑,因为你还没有完全理解OOP.但话说回来,它也不是编程的圣杯,所以如果你更习惯使用另一种范式,一定要使用它.选择存在是因为我们并非完全相同.使用你最擅长的东西以及你想要做的最好的东西.如果你拥有的唯一工具是锤子,那么每个问题看起来都像钉子......
哦,与流行的观点相反,OOP并不是永远不会编码任何两次.那是DRY(不要重复自己)的校长.虽然它经常与OOP一起使用,但它不是直接附加的.事实上,我建议你在开发时不要遵循DRY作为规则.拍摄它作为一个目标,但让它成为一个规则而不是一个规则.弗雷德布鲁克斯说,计划抛弃一个; 无论如何,你会的.(来自神话人月).如果你绝对不会重复自己,那么当你第一次扔掉你没有做对的东西的时候,你将会重新做很多工作.只有当它的构建和运行良好时,你应该开始减少它并真正使代码干燥.(至少个人意见)......
为您提供一个关于您主要担心的简单示例:
$list = DB::query($query);
foreach ($list as $person)
{
// $person->name
// $person->address
// .. and so on
}
首先,如果你有一个点,你是每个人都有一个类的实例,当你想要一个列表时,那么从一开始就是糟糕的编程,你应该检查自己的OOP知识(尽量不要粗鲁,对不起,如果我是).