面向对象思维

面向对象思维

     从宏观上，主要体现在分层，采用包或组件来区分。每一层负责具体的内容。典型应用为mvc。这是保证系统扩充性，可维护性和灵活相应需求的必要条件。 各层之间耦合度尽量降低，如果说每层的业务比较复杂，我们也可以将各层独立出来成为一个服务器，具体的交互方式很多。这里也有很多的概念，比如面向服务，分布式，集群等等。

    

    从细节上，各层直接唯一的交互就是接口或抽象类，不要让层之间揉杂一些核心业务，彼此之间互相牵扯。例如，页面不要有业务逻辑代码，更好的是不要有后台代码（可以用视图层框架，例如veloctiy），这样后台的改动基本不需要修改页面，并且后台的业务改动会直接反映到页面上 。

    那么具体到代码细节我们又该如何考虑呢，例如要实现一个如下一个功能：

    扫描商品，最后生成汇总单，其中没扫描一次那么缓存一个sku，如果sku相同累加数量。可以扫描多种sku，最后点击生成汇总单产生汇总单。习惯上我们可能会一条线下来，但是这里面包含很多逻辑，这样的思维比较不容易掌控整个程序片段。如果分开来考虑就好很多：

1、基本参数校验，这是一个方法（当然该方法不具有通用性，如果有那么应该抽象出来公用）

2、商品缓存系统，负责缓存sku,统计次数（这里为了保证各个用户操作不冲突，采用session方式），其实这里也可    以抽成一个方法

3、给出最后操作提示

    以上的流程就可以将sku的扫描缓存完成，下次如果出现问题，采用模块的方式（一个个方法）来思考，将降低问题分析的复杂度往往能一针见血（培养这种习惯很重要）。

    那么再说到生成退货上架汇总单，同样有一个主流程，这个流程好似有几个模块组成（方法）。

1、基本参数校验（方法）

2、获取缓存（其实可以将该方法封装到上面提到的缓存系统中）

3、业务操作
   3.1获取关联数据
   3.2生成汇总单
   3.3每个sku生成一个上架单
   3.4处理库存信息，减去合格量，锁定库存，增加空间锁定量
   3.5处理关联信息

   3.6返回提示

4、返回到其它模块（这里也有分层的思想，控制层做到）

那么会有这样的结论，在代码细节中，我们应该有模块化的思维习惯，将不相互关联的业务封装成方法。这样的好处：

1、简化思维复杂度（其实是理不清）

2、提高代码复用度（方法的粒度控制得当，就好比我们将数据库的连接操作封装成一个类一样）

通过宏观和微观以及代码细节的考虑，逐渐培养这样的习惯。

当然仁者见仁智者见智，期盼大家提出更好的思维和方式。