用类的设计原则编写vue业务组件

在软件开发过程中，为了降低软件复杂度，前人总结了很多经验。比如在保持软件内在联系的前提下，进行分层分割分解软件系统。但是在保持软件内在联系的前提下，如何分层分割系统，分层分割到什么样的程度，并不是一件容易的事，这方面有各种各样的分解方法，比如：关注点分离，面向方面，面向对象，面向接口，面向服务，依赖注入，以及各种各样的设计原则等(百度百科)。

站在上帝视角看待一个软件，分层是必不可少。比如java的web开发，采用MVC模式分层，使得项目结构清晰简单。分层下，又可以根据功能分解成一个一个的高内聚模块。模块下，可以根据设计模式中的单一责则原则，分解成一个一个独立的、拥有行为与状态低耦合类。不过，分解成独立的类还是不能很好完成具体功能。《面向对象分析与设计》中提到类的聚合，即一个类包含多个独立类，共同完成一个完整功能。此外，类还有组合、关联、依赖等关系

(参考https://www.cnblogs.com/shijingjing07/p/6228417.html或者《面向对象分析与设计》)。

根据以上原则，就可以把一个vue的业务组件抽象成一个聚合类或组合类。一个业务组件，往往可以看成一个展示页面。但是这远远不够，良好的项目目录结构是非常清晰的。根据MVC设计模式，可以把一个vue的功能小组件分成Model、View、Controller层。Controller层负责对后端服务的请求与处理，View层负责HTML的处理与展示。因为View层的数据结构一般由后端服务提供，所以Model层可以省略。这样，就可以把Controller层与View层，聚合成一个强联系的功能小组件。多个功能小组件组合在一起，就能形成组成的业务组件(以上根据自己思路整理)。

这里的功能小组件，想法是根据api请求划分边界。比如java以线程为边界处理复杂的并发请求，大大简化了代码编写难度。以api请求为边界，目的是使功能小组件责则单一，代码结构清晰。根据设计模式的开放封闭原则，以后功能小组件的扩展，应在内部进行。下图是根据当前思路划分的一个业务组件的功能小组件目录。

上图中的components，并不是指公用的components组件。根据设计模式的类组合原则，功能小组件一般不能被其他业务组件使用。如果功能小组件需要被多个业务组件使用，可以把功能小组件层次上升到公用功能组件层次。

层次结构上，功能小组件->业务组件->通用组件。之所以要这样划分具体层次，依据是“约定优于配置”。

下图为v-swipe轮播功能小组件具体代码。如果轮播图需要添加点击事件，在功能小组件内部即可进行。如果所有功能都聚集到业务组件上，业务组件会显得异常臃肿，可读性差。

在业务组件上，组合已有的功能小组件。

这样的话，项目的目录结构清晰，层次分明。而且，当需要对具体的某个功能小组件样式进行修改或者扩展，也可把改动的代码降低到最少。

《代码重构的艺术》上一直强调，代码首先是人看的，其次才是机器使用。编写清晰易读的代码，应该在开发的整个过程中进行。

示例项目：https://github.com/sale-oranges-xyz/orange-shop/tree/master/mobile