见到很多朋友开始使用php的面向对象,结合自己的一些经验，和大家聊聊类的写法
关键词：php,db,global db,html,smarty,machine
见到很多朋友开始使用php的面向对象,结合自己的一些经验，和大家聊聊类的写法 见到很多朋友开始使用php的面向对象方法设计了。这是一个好的现象，不过同时也感到有很多的不足，于是我打算结合自己
的一些经验，和大家聊聊类的写法
建议写类时多从以下几个方面考虑:
1:耦合度高的写在一起，耦合度低的独立出来。我见过一些类，那是太恐怖了，什麽都写在里面。于是弄得整个类过于臃肿，
而且在每次调用的时候都会有一大堆函数是没有被调用过一次的，这样就会造成资源的严重浪费，并且对于日后更新类也
是相当不利的。所以常常见到有些朋友每做一个新的项目时，都要重新开发类，为什麽？因为原来的类中有太多的东西已
不适合当前项目了。
2:函数职能细化。
也许您在写一个简单的类的时候会以为完全没有必要细化，不过我们现在仅从理论层面来分析，一般来说
函数职能细化便于日后的维护与更新，假如把一大堆事情都放到一个函数里面实现，那么以后想增加某些功能的时候会发现
该功能的部分代码之前已经写过了，可是却被写入了另一个函数之中，这时只能面临两种选择 a:复制粘贴，两个函数中有一段
同样或类似的代码，这对于类来说无疑是糟糕的。b:把原函数的这部分代码删掉，独立出来，这对于开发者来说是非常痛苦的事
情。因为这很有可能造成您的其它函数调用这个函数的时候出现问题，并且当这种问题是隐性的时候随时会危及您的系统，
假如在一开始设计类的时候，就把函数职能细化了，以后就会减少此类问题的出现。
3:深度考虑类的重用性。
举个例子，一些朋友在类的外部用了db数据库类，然后在类里面这样使用：global $db，这就无形中要求其它人也使用和您一样的数
据库操作类，否则就要修改类的代码 这是很糟糕的，一个好的类是不会鼓励使用者直接修改类代码的，冲顶会让使用者继承重载。
为什麽？原因很简单。因为当类的开发人员更新了类版本之后，假如您要使用新版本，您原来做的修改就全部没用了。所以在设计类
的时候必须要考虑到这一点，也就是怎样让使用者更好的重用（某些需要量身订做的函数可以让别人重载）。
4:返回值应尽量简单，只返回必须的值即可。
很多朋友写类的时候，把html也加入到返回值里面了，可能就您当前的项目而言这很方便——您可以少些很多html。
可是朋友，您想过没有，当您下次做别的项目的时候，这些html怎样办？修而改之？ok，允许您修改，那再下一次呢？下下次呢？每次都修改？
先不考虑这样做麻不麻烦，我想请教您怎样做类的更新？写了如此多个，到底更新哪一个？更何况极有可能每个都不同。
大家多多思考一下类似smarty这样的类，为什麽我们无论做什麽项目，几乎都只需要把它们包含进来，实例化之后直接使用就可以了，并且我们
又发现它们其实也提供了很多允许我们重载的地方例如：smarty的caching,cache_lefttime,template_dir……这些属性
这样的类才是便于使用的。 [ 本帖最后由 machine_马 于 2006-12-7 12:21 编辑 ]
回复 #1 machine_马 的帖子 Object Inheritance..
要是结合实例就更能说明问题了.
实例可以参看这一片
http://www.phpchina.com/bbs/thread-13149-1-1.html
写得也不是很好，还有很多不足，希望大家多多指出，多多批评。 [ 本帖最后由 machine_马 于 2006-12-7 17:38 编辑 ]
很好了，写了关键的东西，代码大全里面也着中提到了耦合，还有低扇入，高扇出等。csdn.net上可以看到改章节。
支持OOP
5个面向对象设计的基本原则还是很重要的。
SRP 单一职责原则
就一个类而言，应当仅有一个引起它变化的原因。
OCP 开放-封闭原则
软件实体（类、模块、函数等）应当是可以扩展的，但是不可修改的。
LSP Liskov 替换原则
子类型必须能够替换掉它们的基类型。
DIP 依赖倒置原则
抽象不应当依赖于细节。细节应当依赖于抽象。
ISP 接口隔离原则
不应当强迫客户(程序)依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。
内容还不错，顶下
