加载类
1.加载类的方法
加载类可以使用include、require、require_once三种中的任意一种，每个关键字都有两种方法，但是这种方法的缺点是需要加载多少个php文件，就要写多少个加载类的方法。一般也就需要加载一两个类，所以这种写法很常用。
//include("./Ren.class.php"); //include "./Ren.class.php"; //require("./Ren.class.php"); //require "./Ren.class.php"; //require_once("./Ren.class.php"); //require_once "./Ren.class.php";
自动加载类：
如果要使用自动加载类，要满足下列2个条件
1.所有文件都放在同一个目录下；
2.所有类文件的命名规则一致；
//使用条件：1.所有文件都放在同一个目录下；2.所有类文件的命名规则一致。 /*function __autoload($classname)//自动加载类的方法，classname代表类名。 { require $classname.".class.php";//可以用第一种加载类的任意一种方法。 }
例如：网文件里加载类名为Ren的类 function __autoload($Ren)
{
require $Ren.".class.php";//代表加载了class.php文件下的Ren类。类名后面加上文件名个文件格式。
}
$r = new Ren(); */
设计模式
1.单例模式
类的计划生育：类智能造出一个对象来，不能多造，更不能随便取造。
单例模式又称为职责模式，它用来在程序中创建一个单一功能的访问点，通俗地说就是实例化出来的对象是唯一的。
所有的单例模式至少拥有以下三种公共元素：
1. 它们必须拥有一个构造函数，并且必须被标记为private
2. 它们拥有一个保存类的实例的静态成员变量
3. 它们拥有一个访问这个实例的公共的静态方法
单例类不能再其它类中直接实例化，只能被其自身实例化。它不会创建实例副本，而是会向单例类内部存储的实例返回一个引用。
例题：
class Single { private $name;//声明一个私有的实例变量 private function __construct(){//声明私有构造方法为了防止外部代码使用new来创建对象。 } static public $instance;//声明一个静态变量（保存在类中唯一的一个实例） static public function getinstance(){//声明一个getinstance()静态方法，用于检测是否有实例对象 if(!self::$instance) self::$instance = new self(); return self::$instance; } public function setname($n){ $this->name = $n; } public function getname(){ return $this->name; } } $oa = Single::getinstance(); $ob = Single::getinstance(); $oa->setname('hello world'); $ob->setname('good morning'); echo $oa->getname();//good morning echo $ob->getname();//good morning
//从类外部控制 /*$dx;//定一个变量$dx class Dog//Dog类 { } if(empty($dx))//判断变量是否为空，为空返回true，不为空返回flase。 { $dx = new Dog();//如果变量是空的就造一个对象给$dx。 } else { $a = $dx;//如果不为空，就把$dx给$a。 }*/ //这样这个界面就不能多造了，但是别的类还可以继续多造，比如$b=new Dog(),$c=new Dog().从类外部控制不能控制全部的，所以要转到内部控制。
//从类内部控制
内部控制的思路
//1.让该类在外界无法造对象,使用private.
//2.让外界可以造一个对象，做一个方法返回对象。
//3.在类里面通过静态变量控制返回对象只能有一个。
class Dog { state $dx; public $test; private function __construct()//为了不让外界访问，先把访问模式变为私有的private，外界无法new对象了。造下面的DuiXiang方法内部访问，返回对象。 { } static function Duixiang()//做一个方法，调一下就返回一个对象。外部无法调用此方法，先把此方法变为静态的，不用造对象访问，直接用类名来调用。但是类名每调用一次都会返回一个对象，还是起不到目标效果。做一个成员变量$dx，用来存储对象。 { //return new Dog();//返回一个对象 if(empty(self::$dx))//先判断$dx这个变量是否为空 { self::$dx = new Dog();//如果变量$dx是空的，就造一个对象给$dx } return self::$dx;//如果变量$dx不为空，就不用造了，什么都不执行，直接返回$dx。 } } $a = Dog::DuiXiang();//造一个对象$a $b= Dog::DuiXiang();//造一个对象$b $b->test="hello"; echo $a->test;//输出结果为hello和$b的一样。 虽然造了两个对象，但是是同一个对象，无论调多少，也都是一个。
工厂模式
//写一个父类用子类去继承父类比较安全
abstract class Yunsuan//做一个抽象类 { public $a;//变量a public $b;//变量b function Suan()//方法Suan { } } class Jia extends Yunsuan//做一个YunSuan的子类 { function Suan()//对Suan的方法重写 { return $this->a+$this->b; } } class Jian extends Yunsuan//修改减法的功能只需要修改这个文件就可以 { function Suan() { return $this->a-$this->b; } } class Cheng extends Yunsuan//需要扩展功能的话直接再新写一个文件就可以，去掉一个功能直接删除相应文件就可以。 { function Suan() { return $this->a*$this->b; } } //$j = new Jia9);//箱实现加法就直接写一个加法对象，调用里面的Suan方法就可以了。 //$j->Suan(); //工厂类，生产对象。给不同的参数，生产不同的对象。 class GongChang { static function ShengChan($f)//为了比较方便调用，做成静态的，直接用类名调用。 { switch($f) { case "+"://如果是+，就返回Jia的对象。 return new Jia; break; case "-": return new Jian;//如果是-，就返回Jian的对象 break; case "*": return new Cheng; break; } } } $r = GongChang::ShengChan("+");//实行加法运算，就传一个“+”到类GongChang里面，然后就会返回一个new Jia，也就是加法的对象对象（YunSuan的子类） $r->a=10; $r->b=5; echo $r->Suan();
上面的内容就是工厂模式，工厂模式就是指有一个工厂类，根据给的参数的不同生产出不同的对象。一般来说生产的对象有一个相同父类的，就比如说上面的做的那些类，有一个YunSuan的父类，Jia、Jian、Cheng三个子类。然后工厂类就返回这三个子类的任意一个，根据参数的不同返回相应的参数。
面向对象的六大原则
OOP基本上有6大原则，而实际上都是互补的，也就是说一些原则需要利用另一些原则来实现自己。6大原则如下：
1) Open-Close Principle（OCP），开-闭原则，讲的是设计要对扩展有好的支持，而对修改要严格限制。这是最重要也是最为抽象的原则，基本上我们所说的Reusable Software既是基于此原则而开发的。其他的原则也是对它的实现提供了路径。
2) Liskov Substituition Principle（LSP），里氏代换原则，很严格的原则，规则是“子类必须能够替换基类，否则不应当设计为其子类。”也就是说，子类只能去扩展基类，而不是隐藏或覆盖基类。
3) Dependence Inversion Principle（DIP），依赖倒换原则，“设计要依赖于抽象而不是具体化”。换句话说就是设计的时候我们要用抽象来思考，而不是一上来就开始划分我需要哪些哪些类，因为这些是具体。这样做有什么好处呢？人的思维本身实际上就是很抽象的，我们分析问题的时候不是一下子就考虑到细节，而是很抽象的将整个问题都构思出来，所以面向抽象设计是符合人的思维的。另外这个原则会很好的支持OCP，面向抽象的设计使我们能够不必太多依赖于实现，这样扩展就成为了可能，这个原则也是另一篇文章《Design by Contract》的基石。
4) Interface Segregation Principle（ISP），接口隔离原则，“将大的接口打散成多个小接口”，这样做的好处很明显，我不知道有没有必要再继续描述了，为了节省篇幅，实际上我对这些原则只是做了一个小总结，如果有需要更深入了解的话推荐看《Java与模式》，MS MVP的一：本巨作！^_^
5) 单一职责：一个类的功能尽量单一，降低耦合
6) Law of Demeter or Least Knowlegde Principle（LoD or LKP），迪米特法则或最少知识原则，这个原则首次在Demeter系统中得到正式运用，所以定义为迪米特法则。它讲的是“一个对象应当尽可能少的去了解其他对象”。也就是又一个关于如何松耦合（Loosely-Coupled）的法则。
好了，以上是6大原则（或法则）的介绍，对这些原则的深入研究正是如何得到设计模式的道路。在进行了深入了解后我们就可以开始看看设计模式了，设计模式正是对这些法则的应用，著名的设计模式有四人帮（Gang of Four，GoF）的23个模式，除此之外还有很多其他的一些著名模式，大家可以慢慢研究，如果能自己产出一两个模式的话那就太好了，证明你也是高手了！^_^