php中面向对象开发探讨

Question

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

你提出的问题就是重构
重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。拆分你先有的类，形成一个个单一对象，有如你的 UserScoreMgr类
需要注意的是：继承的层次不要太多，一般以不超过二个层此为宜

Answer 8

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

Answer 9

其实oop和设计模式的书也一直在看，只是以前毕竟没有做过这方面，希望能够站在你们巨人的肩膀上，少走点弯路而已，最终都得靠自己去做。在做之前多听听大侠们的意见，终究是好的。

Answer 10

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