如何把简单代码复杂化

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

posted @ 2019-03-25 09:56  huazhiliange  阅读(330)  评论(0编辑  收藏  举报