就好比print一句hello world吧。main函数里print一下？太面向过程，太low了。服务器
得封装一个类。叫Printer. Printer有个成员方法，叫print。架构
可是！光一个类太low了，之后要是有不一样的实现怎么办？因此得加一个接口。PrinterInterface。函数
可是！interface是没有实现的，仍是要有默认实现才行。因此得加个虚拟类，AbstractPrinter实现PrinterInterface，而后Printer继承AbstractPrinter。编码
可是！你有了那么一套，该怎么建立实例呢？直接new Printer()？太low了，那叫实现依赖。确定不行的，因此要搞一个工厂类，PrinterFactory，PrinterFactory用PrinterInterface返回实例，这样就隐藏了实现细节了。插件
可是！PrinterFactory自己也是实现类啊，太low了，因此得有PrinterFactoryInterface, AbstractPrinterFactory.命令行
并且在PrinterFactory里面该怎么写呢？直接new Printer()? 太low了。仍是实现依赖。设计
最后，你要把这一堆玩意在代码里组装起来，也太难看了，各类new实现类。太low！对象
好在咱们有个高级玩意，叫依赖注入！把程序对象结构全写到配置文件里面。这一套固然是不能本身造轮子的。配置Spring吧。搞了那么多lib，靠命令行或者IDE的项目管理确定不够啊，得有依赖管理。Maven啊Gradle啊使劲上。继承
最最后，要print的东西怎么传给程序呢？硬编码？命令行传参数？太low！固然得写在XML里头。接口
光是XML固然还不够企业级，再加上DTD验证吧。
而后就涉及到了XML解析的问题了。代码里直接操起parser吗？太low! 固然要写个parser的包装类，interface, abstract class, implementation class, factory class再来一套。毕竟，不能依赖实现啊，之后我要是换parser了怎么办。
因此最后是成品是一堆配置文件，一堆jar，compile出来的程序200MB。
IDE得装上300个插件，打开项目硬盘响老半天吃掉2GB内存，而后一堆插件弹提示要求升级。
哦对了，在这一切发生以前，还得画UML图呢。
三年后项目完工了，部署到客户的服务器上一跑，立马崩溃，一地的stack trace。原来客户服务器上用的是JDK 6而新项目须要JDK 8. 而后问客户大家不能升级吗，答案是不行，由于另一个企业级开发组给作的企业级解决方案只支持JDK 6。接着客户把大家的架构师臭骂了一顿，你搞了那么多设计就没有想过可能会换JDK吗？