有一些关于此事的帖子,但我没有明确知道何时使用面向对象的编码以及何时在include中使用编程功能.有人还向我提到,OOP运行起来非常繁重,并且会增加工作量.这是正确的吗?
假设我有一个包含50个函数的大文件.我为什么要在课堂上打电话?而不是通过function_name()?我应该切换并创建一个包含我所有功能的对象吗?优势或具体区别是什么?它为PHP中的代码OOP带来了哪些好处?模块化?
在很多场景中,程序编程都很好.使用OO是为了使用它是没用的,特别是如果你最终会得到POD对象(普通旧数据).
OO的力量主要来自继承和多态.如果您使用类,但从不使用这两个概念中的任何一个,那么您可能不需要首先使用类.
OO闪耀的IMO最好的地方之一是允许你摆脱开关型代码.考虑:
function drive($the_car){ switch($the_car){ case 'ferrari': $all_cars->run_ferrari_code(); break; case 'mazerati': $all_cars->run_mazerati_code(); break; case 'bentley': $all_cars->run_bentley_code(); break; } }
以其OO替代方案:
function drive($the_car){ $the_car->drive(); }
多态性将允许基于运行时信息发生适当类型的"驱动".
关于多态性的注释:
这里的第二个例子有一些前提:那就是所有汽车类都要扩展抽象类或实现接口.
两者都允许您强制扩展或实现类来定义特定的函数,例如drive()
.这是非常强大的,因为它允许你drive()
所有的汽车,而不必知道你正在驾驶哪一辆; 这是因为他们正在扩展一个包含该drive()
方法的抽象类或实现一个强制drive()
定义该方法的接口.
所以只要你确保你的所有特定的汽车要么扩展抽象类car
或实现一个接口,如canBeDriven
(两者都必须申报的drive()
方法),你只需拨打drive()
你知道一个对象上的方法是一辆汽车(但不什么类型的汽车),而不用担心它没有被定义,因为PHP会给你带来致命的错误,直到你在特定的汽车类中定义这些方法.
我会尽量保留我的答案,因为Majd Taby和Coobird的答案非常好.
多年来我一直是一个程序员程序员,并没有与OOP编程作斗争,但从未真正看到太多相关性......直到我开始在团队中工作并构建更重要和复杂的项目.
在我看来,当您需要为更复杂的应用程序编写精简,易于维护的代码时,OOP真的很棒.并且请注意,不是在任何情况下,但有一些程序不能很好地发挥作用.
我的大多数OOP实现的例子都是针对那些项目,我有几件事情都是相关的,但都有些不同.有很多表格,很多用户,很多产品等的网站.
它们都有类似的行为名称,如print(),update()等......但是通过将它们封装为对象并改变类中的方法实现,我可以使我的代码在运行时非常简单和整洁.此外,这个是关键,尽管有不同的行为,我可以在整个应用程序中使用相同的方法调用处理不同的对象.它允许第二个开发人员在我处理更深层次的代码时处理实际实现.
我不知道这是否有助于任何人,但不是很久以前在你的情况下,我喜欢OOP.
在程序中使用面向对象的编程方法而不是过程编程方法并不真正依赖于语言(无论是否为PHP),而是依赖于您尝试解决的问题类型.
(我只是在我的例子中使用伪代码,因为我对PHP不太熟悉.)
例如,如果你有一个程序,你只是按顺序执行一堆函数,那么程序就可以了.例如,如果它是一个简单的字符串操作程序,程序方法就足够了:
perform_truncation(my_string, 10) to_upper(my_string) perform_magic(my_string, hat, rabbit)
但是,如果您要处理许多不同的项目(例如文件或任何其他表示的对象),那么面向对象的方法会更好.
例如,如果你有一堆Car
s并想要它们drive
,那么在程序上,你可以做以下事情:
drive_car(first_car) drive_car(second_car)
在OOP中,Car
可以驱动自己:
RedCar myRedCar(); BlueCar myBlueCar(); myRedCar.drive(); myBlueCar.drive();
而且,由于每辆车都是不同的级别,因此可以对其行为进行不同的定义.此外,它们可以是子类,Car
也可以具有共同的功能.
这实际上归结为问题的类型,它使得程序方法比面向对象更好,反之亦然.
除了程序性或面向对象的问题之外,拥有一个具有许多功能的源文件可能是一种"代码味道".对于包含许多功能的类,也可以这说,这些功能可以作为单独的类中的单独功能更好地执行.
这里的问题可能是代码组织,而不是决定选择程序或面向对象的编程.将功能组织到单独的源文件中可能是这里所需要的,而不是放弃编写程序的程序方法.
毕竟,在程序编程方法中编写了大量程序,这些程序编写得很好,易于维护.
假设我有一个包含50个函数的大文件,为什么我要在类中调用它们?而不是通过function_name().我应该切换并创建包含我所有功能的对象吗?
移动到OOP不应该像上面描述的那样被视为简单的"切换".
OOP需要一种完全不同的编程思维方式,包括重新布线你的大脑.由于大脑的重新布线不会在一夜之间发生,许多人不愿意将自己暴露在所需的重新布线过程中.不幸的是,重新布线需要投入时间和精力:研究,教程,试验和错误.
它实际上涉及退一步并了解OOP背后的概念,但回报将非常值得它作为在www前几天经历这个过程的人说话.
在你得到它并遵循日常的OOP最佳实践后,你会告诉别人你的编程生活如何变得更好.
一旦你真正了解OOP,你就会回答自己的问题.