php中面向对象开发探讨
一、我在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的飘过.