设计模式随笔

设计模式的本质

如果各位参加工作了，碰到写c出身的程序员做c++或java，会觉得他写的代码很难读懂，这不是你的问题，是这位c出身的程序员没有理解高级编程语言的精妙，就急急忙忙的开始写代码了。我的第一份工作真的很幸运，是加入一个用原生java做的国产办公软件的公司——永中软件（吐槽一下，真的比wps厉害，不过是主要提供给政府和军队在用，所以知名度不高）没有用spring框架，所有的功能都是由java代码搭建的，里面的设计模式数不胜数，所以我敢讲讲设计模式。设计模式我谈的是面向对象编程的设计模式，他的本质是整合代码，于一处功能的实现，一定是代码量的增加，内存更多的消耗，代码效率的下降，于一个系统而言，一定是重复代码量的减少，更好的封装，更简单的阅读，更健壮稳定的系统。

一个spring引发的血案

spring的出现，其实也是伴随着利弊的。spring让java成为搭建平台最便捷的语言之一，但也让很多java初学者对于高级语言的设计模式两眼一抹黑。99%的java程序员，可能都是干着ctrl+c/ctrl+v复制一个项目，然后修改一下配置，写写controller/service/dao，一天天的熟练（麻木），变成一个毫无感情的代码机器。所谓生于忧患，死于安乐。很多初学java的人会觉得spring神奇，由于我第一份工作的磨练，我实际接触spring的时候我已经对javase部分熟练的令人心疼了（一年里在原生的java项目中敲了10万行代码），再进入下家公司去了解spring，我看到他的功能能感受出他是如何实现的。spring的出现让java开发只用关注于业务里实际的逻辑（而绝大多数的逻辑仅仅是数据的搬运），架构师成为了框架搬运工，大大降低时间成本的同时也降低了准入门槛。所以为什么现在有那么多培训机构开编程课就是java，没有c++，没有c，这才是本质。我觉得作为程序员，不能觉得其他程序神奇，只能觉得它精妙。

那么有朋友问了，我就是一个简单的搭一个服务，从数据库里拿点数据直接给前端展示，设计模式在哪里？是的，这个问题我很难回答，而且如果工作中大部分出现的都是这种需求，我只能说请尽快熟练你的技能，从这种最底层的体力劳动中脱离出来。当面对的是一个业务模型的设计，一个框架的搭建的搭建，或者一个复杂业务的逻辑层处理时，才会谈到设计模式。否则你就只是调用spring框架里一些别人写好的模式。

面向对象编程真的完美吗

前一段举例的是用不到设计模式，这一段我想谈谈过度设计。什么是过度设计？我认为过度设计就是基于当前的业务需求，以及现阶段的发展来看，只在一处生效的复杂代码块将其不断抽象封装，以期未来对他进行完美的构建。这还不够，还要将他的产生的对象再管理起来等等等等，然后感觉很棒的想着，可算是体验了一把面向对象编程，以后再有相似的业务需求进来，我就只要换个参数调相同的方法，或是我的哪个抽象类重新实现一下就好了，但是，往往越复杂的业务越具有唯一性，杠精说，所以我才把通用的给抽象出来啊。。。这事正说反说反正都能说通，大部分情况没必要的，因为更多的情况是你要在另一个项目中实现相同的功能，而非在当前的项目中实现相似的功能，这才是我想表达的意思，那么当你在复用代码的时候，有意思的事情就发生了，我得把一整个封装好的体系全抽出来，再原原本本的放到新项目中去，依赖关系错综复杂，本来一个长点的方法复制粘贴的事情就变成了一堆对象的复制粘贴，再修改一下import地址。。。当所有的红线全消失的时候，大大的舒了一口气的同时，也恨恨的想当初的自己到底在干嘛。

寻求平衡

封装还是不封装，这是个问题。我写代码的时候，最让我苦恼的从来不是业务的实现，也不是第三方jar包的引入，而是如何将代码的复杂度保持在一个相对合理的水平上。即又有一定的封装，方便理解和阅读，又基于现状不过度去封装，方便自己或别人“借鉴”。
说直白点吧
1：一个方法里的if/for/while这种嵌套关系>=3时，就要进行逻辑的修改也好，对于嵌套中的逻辑进行再封装也好，反正要改，然后给封装的方法用/**/加好注释，确保别人在ctrl看这个方法时，能直接读到注释。
2：当你感觉差不多的代码块出现了不止一次时，封装！
3：当你觉得当前对象承受了他定义之前的事情时，封装！给这些越界的事情找个合适的对象去负责。
4：当你“借鉴”别人代码时，发现上述问题了，封装！
5：当你觉得这个方法的特征抽象出来后，以后万一有人要用就可以直接调用你的方法，住手！真有人用的时候那人也会酌情封装的