从大学开始接触java的时候记忆最深的一个话是“万物皆对象”[现在做.net了]，就是说什么东西都是对象把，呵呵。。然后就开始了面向对象之旅。就是把一个东西包装成类，包括对于那个东东的描述，行为等。。。然后你就可以实例化他，通过继承扩展他。这样子类既能添加新的方法，属性，也能拥有父类的属性，方法，只要不是父类私有的，如果你那天不高兴了，还能把父类的方法覆盖掉。。写自己想要的实现。这样是不是很棒呢~共有的东西我们就抽出来作为父类，然后子类不用写也能用了。。这就是面向对象中的一部分，继承了。
可惜的是当你接触设计模式以后你可能会看到的一个原则，“多用组合，少用继承”，为什么呢，接着就从代码开始说把，一些的例子纯属假设性成立的情况下的。。呵呵。
现在你的客户要你写个小东西，用来描述人的。人肯定会有共同的行为了，例如”笑“把，恩，具体什么人先不理了，我现在想到的是，人都会”笑“，美女可能笑的好看点~呵呵。所以先定义一个父类把。我们在给“人”加几种属性的描述；
public class Person
{
public Person()
{
//
// TODO: 在此处添加构造函数逻辑
//
}
protected string sex=string.Empty;
protected string name = string.Empty;
protected int age;
public string Sex
{
get { return sex; }
set { sex = value; }
}
public string Name
{
get { return name; }
set { name = value; }
}
public string Age
{
get { return age; }
set { age = value; }
}
public string Laugh()
{
return "laugh ^_^";
}
}
好了，“人的共有属性和一个行为”我们定义完了，然后我们加入个美女把，^_^,当然她也是属于人这个种族的了。。。。所以她肯定继承了人的属性和方法了。
public class Girl:Person
{
public Girl()
{
//
// TODO: 在此处添加构造函数逻辑
//
}
}
一个不能说明什么把，那我们在加入些别的把。。。
public class Boy:Person
{
public Boy()
{
//
// TODO: 在此处添加构造函数逻辑
//
}
}
public class Baby:Person
{
public Baby()
{
//
// TODO: 在此处添加构造函数逻辑
//
}
}
恩，好了，都加上了，然后我让他们笑一下把
Girl a = new Girl();
Boy b = new Boy();
Baby ba = new Baby();
Response.Write(a.Laugh());
Response.Write(b.Laugh());
Response.Write(ba.Laugh());
输出：laugh ^_^laugh ^_^laugh ^_^，恩，都笑了，虽然后边两个我没什么兴趣看到。。。不过都笑了。=_=..是不是看到继承的强大了呢？子类里我们可是什么都没写呀。恩，我们可以交差了。
可是，有一天这个让人头疼的客户突然想到。。不能是一样的笑呀。。。要让美女”微笑“，让男生“狂笑”，让小孩”傻笑“，让XX“X笑”，他还想加入“去世的人”这中类别。。。你一听是不是也开始笑了。。。对，继承会让死人也笑的，好吧，我覆盖掉父类的方法把。让具体的人去实现具体的笑法。。
public class Girl:Person
{
public override string Laugh()
{
return "smile";
}
}
public class Boy:Person
{
public override string Laugh()
{
return "guffaw";
}
}
。。。。。。。。。。。
好了，改完了。。。各笑各的去吧。。。你也可以笑了。。。可是客户还没笑呢。当你那去交工的时候，他突然对你说，还不行。他想让美女能微笑也能傻笑~^_^...好了，如果你可以得罪他就给他一拳把。。。不行？那回去继续改把。。怎么改呢，好吧继续还是继承把。。。然后我在子类中扩展其他的行为。如果你不怕那个客户又出新花招的话。。那就这样该把。如果你怕了的话，恩，那开始考虑不用这样直接的继承了把。考虑用别的方式去实现把。。。或许你会想到的是围绕的就是”笑“这个行为出现的变化，那可不可以不要在继承中具体实现继承这个行为呢？如果我们在继承中定义了是人的属性，然后把”笑“这个行为拿出来，具体的时候再组装不就行了。。到时你的客户想让谁怎么笑就怎么笑了。。所以从父类开始下手把。先把集体的实现类改成抽像类
public abstract class APersons
{
protected string sex=string.Empty;
protected string name = string.Empty;
protected int age;
protected IAction action;//加入了一个行为的接口
public IAction Action//指定具体的行为：我们这里当然是怎么“笑”了。。
{
get
{
return action;
}
set
{
action = value;
}
}
public abstract string PerformLaugh();//子类在具体实现笑把。
}
然后加入这个行为的接口把
public interface IAction
{
string Laugh();
}
方正现实了这个接口的行为都要笑。。怎么笑就不理他了。。继续写实现了接口的行为类。。。
public class smile : IAction
{
public smile()
{
}
public string Laugh()
{
return "smile ^_^";
}
}
public class guffaw:IAction
{
public guffaw()
{
}
public string Laugh()
{
return "guffaw ^_^";
}
}
然后测试一下把：先测试美女~
APersons f = new Female();
f.Action = new smile();
Response.Write(f.PerformLaugh()+"微笑<br>");
f.Action = new guffaw();
Response.Write(f.PerformLaugh() + "狂笑ing<br>");
f.Action = new giggle();
Response.Write(f.PerformLaugh() + "傻笑<br>");
输出：
smile ^_^微笑
guffaw ^_^狂笑ing
giggle ^_^傻笑
再试试小破孩。。。
APersons f = new Child();
f.Action = new smile();
Response.Write(f.PerformLaugh()+"微笑<br>");
f.Action = new guffaw();
Response.Write(f.PerformLaugh() + "狂笑ing<br>");
f.Action = new giggle();
Response.Write(f.PerformLaugh() + "傻笑<br>");
输出：
smile ^_^微笑
guffaw ^_^狂笑ing
giggle ^_^傻笑
好了。这样就把属性和行为分离开了。。如果客户要多几种笑法也很容易加了，想让谁怎么笑也能了。。。如果他笑了，你也能“笑”了。。
这个好像就是策略模式了把。。。呵呵。。 感觉呢，做项目就是在挖坑埋自己。。。。。如果你有足够的经验和预见的能力，良好的设计会成为你的救命稻草。所不定那一次很突然能把你从坑里拉出来，不然，呵呵，可能会埋完自己一次又一次的。。如果你已经习惯被埋了。。那恭喜你了。。实在太强大了。。我现在是看着前边挖的坑就头痛。。。。=_=
