就比如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吗？