现在需求来了,写个程序,把大象放在冰箱里。把大象放在冰箱里需要几步?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();
}
如果我们再有点时间 可以弄个反射什么的就连上面的修改页省了。只需要修改一下配置文件的键值就行了。
写了这么多除了娱乐一下自己,也复习了一下,如何把业务逻辑和业务逻辑实现分开,怎样面对扩展开放面对修改关闭,以及实现依赖倒置。而这些的前提就是抽象,就是会把大象放在冰箱里。