php中面向对象开发探讨
最近要对以前的一个项目改版，以前写的类基本上都是对一些方法的堆积，一个类都有上百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 迭代器吧。
------解决方案--------------------
其实php的模式结构类似于jsp。如果对jsp的框架理解不错的话。其实道理都是一样的。
------解决方案--------------------
php能将类作为参数传递吗？
 
------解决方案--------------------
你提出的问题就是重构
重构（Refactoring）就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。

拆分你先有的类，形成一个个单一对象，有如你的 UserScoreMgr类
需要注意的是：继承的层次不要太多，一般以不超过二个层此为宜
------解决方案--------------------
其实呢,就算现在看还没有什么来不及的,粗看只要一两个晚上,领会精神.
书里有很多具体解决方案,你完全可以跳到你需要的章节细看.

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

引用:

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