编程思想总计
在程序设计和代码实现上尽量将功能模块化,每个功能的代码实现,要用面向对象的思维来思考问题,在程序设计的世界里,到处都是面向对象,对象包括了方方面面,因为万物皆对象,所以从这个思想来讲,任何的业务逻辑都可以被抽象为有行为的对象。
最近感触颇深的一些思考:
1.尽可能的抽象代码,提高重用性和简洁性
2.抽象和提取的代码易维护、易阅读
3.将同一个业务的代码逻辑的分成次“切分”,如提交一个表单所需的步骤:
3.1 表单校验
3.2 表单参数重新处理,附加参数(可能需要从数据库查询)
3.3 数据入库前可能预先加载一些数据
3.4 表单数据赋值转化为数据库可识别的对象
3.5 插入数据库
这些原子操作尽可能的按逻辑分层或分步骤处理,同属于一类的逻辑或组件严格要求放在同一个方法或类中处理,因为同属一类的逻辑的代码如果散布在程序的各个代码块中,不但不易阅读,而且容易造成逻辑混乱,难以维护,甚至无线挖坑给自己,维护成本高,持续时间长、痛苦且没有任何意义
比如价格转换,必须放在一个通用的切面方法或者单独存放在一个价格转换类中,后续回显到页面时,也要有统一的方法或者类来维护,切莫将相同的逻辑代码散布在各个函数中,假如要修改价格转换规则,可以想象有都恐怖
4.就针对数据库的读取和存入来讲,个人认为尽量将加载和写入的动作封装到一个代理类中,尝试用的数据可以缓存起来,并且定义一个公用类,数据服务类继承即可直接使用。 封装数据服务类的优点是,业务逻辑和数据库层分离提高可读性和维护性,合理的设计并且可以减少重复的数据查询
5.尽可能的封装每一个逻辑代码块,因为每一行代码都有被封装或者可以使用面向对象思维设计的可能
6.尽可能的使用枚举将一系列的逻辑装箱,装箱后的枚举类可以作为业务逻流程的一个小的部件来使用,方便、易读、维护性强
7.尽可能的合理的使用设计模式编写代码
8.java的引用类型和是编程语言的一大特色,函数对对象属性的修改和传递让复杂的业务有了被分层和封装的独特之处(与脚本或低级语言比),这样就方便了我们优化分层,代码逻辑一层一层的分开,严格将每个组件的分开,相关逻辑和处理只在相关组件内实现(易于维护、易于阅读、减少代码量、结构清晰,好处太多。。。。)
9.写一个业务逻辑前,先构思整体的业务来如何实现,找出最优实现方案,构思一套方便的、高效的、易读的、可维护性强的代码结构是一个非常重要的环节,不可草草了事,纵然开发时间紧张,因为这个环节决定了代码的最终质量,后续是否天天埋自己挖的坑,就看这个代码业务结构的好坏了