设计模式随笔

浅谈设计模式

  • 设计模式的本质
  • 一个spring引发的血案
  • 面向对象编程真的完美吗
  • 寻求平衡

设计模式的本质

如果各位参加工作了,碰到写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:当你觉得这个方法的特征抽象出来后,以后万一有人要用就可以直接调用你的方法,住手!真有人用的时候那人也会酌情封装的

你可能感兴趣的:(java心得,设计模式,java,项目架构)