面向对象思维
从宏观上,主要体现在分层,采用包或组件来区分。每一层负责具体的内容。典型应用为mvc。这是保证系统扩充性,可维护性和灵活相应需求的必要条件。 各层之间耦合度尽量降低,如果说每层的业务比较复杂,我们也可以将各层独立出来成为一个服务器,具体的交互方式很多。这里也有很多的概念,比如面向服务,分布式,集群等等。
从细节上,各层直接唯一的交互就是接口或抽象类,不要让层之间揉杂一些核心业务,彼此之间互相牵扯。例如,页面不要有业务逻辑代码,更好的是不要有后台代码(可以用视图层框架,例如veloctiy),这样后台的改动基本不需要修改页面,并且后台的业务改动会直接反映到页面上 。
那么具体到代码细节我们又该如何考虑呢,例如要实现一个如下一个功能:
扫描商品,最后生成汇总单,其中没扫描一次那么缓存一个sku,如果sku相同累加数量。可以扫描多种sku,最后点击生成汇总单产生汇总单。习惯上我们可能会一条线下来,但是这里面包含很多逻辑,这样的思维比较不容易掌控整个程序片段。如果分开来考虑就好很多:
1、基本参数校验,这是一个方法(当然该方法不具有通用性,如果有那么应该抽象出来公用)
2、商品缓存系统,负责缓存sku,统计次数(这里为了保证各个用户操作不冲突,采用session方式),其实这里也可 以抽成一个方法
以上的流程就可以将sku的扫描缓存完成,下次如果出现问题,采用模块的方式(一个个方法)来思考,将降低问题分析的复杂度往往能一针见血(培养这种习惯很重要)。
那么再说到生成退货上架汇总单,同样有一个主流程,这个流程好似有几个模块组成(方法)。
1、基本参数校验(方法)
2、获取缓存(其实可以将该方法封装到上面提到的缓存系统中)
3.1获取关联数据
3.2生成汇总单
3.3每个sku生成一个上架单
3.4处理库存信息,减去合格量,锁定库存,增加空间锁定量
3.5处理关联信息
3.6返回提示
那么会有这样的结论,在代码细节中,我们应该有模块化的思维习惯,将不相互关联的业务封装成方法。这样的好处:
1、简化思维复杂度(其实是理不清)
通过宏观和微观以及代码细节的考虑,逐渐培养这样的习惯。
当然仁者见仁智者见智,期盼大家提出更好的思维和方式。