现在需求来了，写个程序，把大象放在冰箱里。把大象放在冰箱里需要几步？1，把冰箱门打开，2，把大象放在冰箱里，3，把冰箱门关上。这是整个程序的业务逻辑。
先写一个接口吧
Public interface 大象放在冰箱里
{
Void把冰箱门打开();
Void把大象放在冰箱里();
Void把冰箱门关上();
}
这个接口，有什么用，和笑话一样可笑，有了它就可以大象放在冰箱里吗？当然不能，但是有了它，可以让我们写的程序更加的优雅（从外观上说），更加的弱化依赖（从结构上说），更加的可扩展（从功能上说），更加......(可以baidu一下找到好的形容词)
Public class BBL
{
Private大象放在冰箱里 _大象放在冰箱里
Public BBL(大象放在冰箱里 (小写)大象放在冰箱里)
{
This._ _大象放在冰箱里 = (小写)大象放在冰箱里
}
Public void Action （）
{
_大象放在冰箱里. 把冰箱门打开();
_大象放在冰箱里. 把大象放在冰箱里();
_大象放在冰箱里.把冰箱门关上()
}
}
好了根据现在的需求能写的都写了，我们等待进一步客户的需求。
需求来了，大象要活的。可以不计其他成本。写点业务逻辑实现吧。
Public Class 方案一：大象放在冰箱里
{
Public Void 把冰箱门打开()
{
联系青岛海尔让他们作个大冰箱；
冰箱到货；
联系江南重工让他们给我们作个打开冰箱门的工具；
工具到货；
打开门；
}
Public Void把大象放在冰箱里()
{
联系农产品让他们提供大量的香蕉；
把香蕉放在冰箱里；
让大象看到冰箱里的香蕉；
等待大象自己走到冰箱里；
}
Public Void把冰箱门关上()
{
利用工具关上冰箱们
}
}
好的，业务逻辑实现写完了，我们 做最后一步吧写运行的程序。
Public static void
{
BBL bll = new BBL (new方案一());
bll. Action();
}
大功告成了 项目结束了？ 如果需求没有变化。但是需求没有变化，简直比中奖还难。
新需求来了。要控制成本，大象不管死活。只要放在冰箱里就行了。下面的情况通常是
**%%@@@?? 抽象出来就是两个字 “骂街”。但是活还是要干的。 重新实现业务逻辑
Public Class 方案二：大象放在冰箱里
{
Public Void 把冰箱门打开()
{
联系苏宁电器让他们运N冰箱；
冰箱到货；
叫人；
打开N个门；
}
Public Void把大象放在冰箱里()
{
联系 兽医；
兽医杀死 大象；
联系屠宰场；
给大象分尸；
把大象分装在n个冰箱里；
}
Public Void把冰箱门关上()
{
打扫现场；
分别关上n个冰箱门（）；
}
}
看看其他的程序 我们改了哪些地方，很幸运我们就改了一个地方
Public static void
{
BBL bll = new BBL (new方案二());
bll. Action();
}
如果我们再有点时间 可以弄个反射什么的就连上面的修改页省了。只需要修改一下配置文件的键值就行了。
写了这么多除了娱乐一下自己，也复习了一下，如何把业务逻辑和业务逻辑实现分开，怎样面对扩展开放面对修改关闭，以及实现依赖倒置。而这些的前提就是抽象，就是会把大象放在冰箱里。