Heim  >  Artikel  >  Backend-Entwicklung  >  php中面向对象开发探讨

php中面向对象开发探讨

WBOY
WBOYOriginal
2016-06-23 14:14:45839Durchsuche

最近要对以前的一个项目改版,以前写的类基本上都是对一些方法的堆积,一个类都有上百k的大小,根本谈不上是面向对象,或者称之为伪对象吧。以以前写的一个User类为例,对有些疑问的几个地方进行讨论下。
一、我在User里要用到$db这个变量,用来查询数据库的,$db是通过db类实例化出来的,那我这个$db是不是在User类的__construct()里就进行实例化呢?这样做的好处就是User类的其他方法可以直接用$db变量了,不好的地方就是我的User类里其他一些方法可能根本不需要用到$db变量,不仅仅是$db变量,还有一些cache对象、webservice对象,都可能有这种情况,也就是说在方法用到的时候去实例化对象,还是__construct()里就进行实例化?或者是不是有什么设计模式来处理这种情况?
二、对类的划分问题。在User类我这里可能有给用户添加物品、删除物品、显示用户物品列表,同样不仅仅只有物品,还有积分、金钱等等,大部分都是增加、删除、显示列表的,这些都放User类里看起来是没有什么问题的,都和用户相关。但是个人总感觉User类纯粹是一些方法的堆积了(尤其是显示列表的那些方法),是不是可以改成这样,比如以积分为例,有一个UserScoreMgr类,继承自User类,然后对积分的操作都放在这个类中,这样是不是好一些?或者同样有什么样的设计模式来处理这个问题?


回复讨论(解决方案)

1, DB类我一直用单例模式,调用静态方法getInstance()取对象,而我习惯于在__construct()中实例化所有程序需要的类。至于该在何处实例化,我是觉得无所谓影响(可能对内存占用有点影响吧),在__construct()中统一处理反倒方便管理。
2, 我也许会这么划分:
添加物品,删除物品,显示用户物品列表
增加积分,减少积分,显示积分
增加金钱,减少金钱,显示余额
这些都可以写成独立的类,因为它们本身互不影响。也不需要继承User,如果你觉的会乱的话,指定这些类实现一个统一的接口。
而User类的工作,只是负责调用,即向这些类传递一些参数

这个没有严格接的界限。如果业务逻辑比较多就要分层了。在数据和数据逻辑,业务逻辑之间分多层。
user是实体严格意义上就是存储用户的信息,然后在创建user相关的业务逻辑。
用户相关的附属的积分,物品,金钱等等和用户相关连的也主要集中在业务了逻辑上。
当然没有完美的设计方式,适合就是最好的。
php的面向对象,“我觉得没几个人敢用”,你很大胆。呵呵,当然任何东西都是喜忧参半的

我不懂什么单例模式也罢,工厂模式也罢,只知道那是php的底层实现模式,如果你们要用底层开发的话,那么像array函数,字符串函数之类的都别用,直接用最原始的php 迭代器吧。

看吧, 当然其它一些有关设计模式和oo设计的书也可以

其实php的模式结构类似于jsp。如果对jsp的框架理解不错的话。其实道理都是一样的。

php能将类作为参数传递吗?
 

我不懂什么单例模式也罢,工厂模式也罢,只知道那是php的底层实现模式,如果你们要用底层开发的话,那么像array函数,字符串函数之类的都别用,直接用最原始的php 迭代器吧。
现在看重构来不及了,需要就提出的问题有个解决方案。

你提出的问题就是 重构
重构(Refactoring)就是在不改变软件现有功能的基础上,通过调整程序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。

拆分你先有的类,形成一个个单一对象,有如你的 UserScoreMgr类
需要注意的是:继承的层次不要太多,一般以不超过二个层此为宜

其实呢,就算现在看还没有什么来不及的,粗看只要一两个晚上,领会精神.
书里有很多具体解决方案,你完全可以跳到你需要的章节细看.

重构的具体做法,和你的现有代码,你的需求细节,你的软件架构,包括你的个人喜好习惯,都有关系,
所以,不认为别人在仅仅看到你帖子里写的这么点内容的情况下, 能给出多具体的方案.
还是要你自己去做.



引用 3 楼 xjl756425616 的回复:
我不懂什么单例模式也罢,工厂模式也罢,只知道那是php的底层实现模式,如果你们要用底层开发的话,那么像array函数,字符串函数之类的都别用,直接用最原始的php 迭代器吧。

现在看重构来不及了,需要就提出的问题有个解决方案。

无所谓,只要代码维护方便,条理清晰,不一定非要较真儿的用啥oop

其实oop和设计模式的书也一直在看,只是以前毕竟没有做过这方面,希望能够站在你们巨人的肩膀上,少走点弯路而已,最终都得靠自己去做。在做之前多听听大侠们的意见,终究是好的。
其实呢,就算现在看还没有什么来不及的,粗看只要一两个晚上,领会精神.
书里有很多具体解决方案,你完全可以跳到你需要的章节细看.

重构的具体做法,和你的现有代码,你的需求细节,你的软件架构,包括你的个人喜好习惯,都有关系,
所以,不认为别人在仅仅看到你帖子里写的这么点内容的情况下, 能给出多具体的方案.
还是要你自己去做.

php做面向对象,那不是搞笑吗?玩java的飘过.

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn