Maison >développement back-end >tutoriel php >php中面向对象开发探讨

php中面向对象开发探讨

WBOY
WBOYoriginal
2016-06-23 14:14:45860parcourir

最近要对以前的一个项目改版,以前写的类基本上都是对一些方法的堆积,一个类都有上百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的飘过.

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn