基础组件是相对于业务功能来说的，因为业务线的事务一般比较繁杂，在没有基础组件的情况下，遇到相似功能的复用大多是直接copy代码然后再粘贴修改。这样的话，类似功能存在多份代码，如果要修改一个BUG，就需要找到所有的相关代码然后再修改，费时费力，效率也不高。而且当需求功能复杂时，代码量也会随之增加，维护成本也相应增加，调试修改都变得很麻烦。所以我们需要在业务层下面抽象出一个基础组件层，该层介于基础库与业务代码之间。
我们来看看这种轮播功能:
这是很常见的内容轮播组件，在编码前我们需要找到这种组件相对变与不变的需求点，
不变的地方：
都具有一系列内容
具有自动播放功能
可以人工进行切换内容
会改变的地方：
图片大小不一样
可能某些产品的需求会有说明文字，某些没有
按钮的样子和位置不一样，某些需求没有交互按钮
不同的产品中，会有不同的动画切换效果
由此可以看出，改变的大多是UI和交互层面的，所以我们可以把本质的不变的东西直接抽象出来，再把UI层面的剃除出去就可以得到以下的设计思路：
1.列表管理功能，管理添加的内容。
2.切换功能，用以切换列表
3.播放功能，用来让内容自动轮播
4.UI渲染功能，通过配置不同的模板来得到不同的UI呈现
以上是按单一职责原则把各功能进行了拆分，抽离了基本逻辑和UI层，用图来描述大概就是这样：
其中，List列表功能管理内容，因为这种切换内容的数据结构是线形的，所以用列表描述就够了，然后其包含了“添加”、“删除”、“插入”和“清除”功能；
Switch切换功能是对列表数据进行管理，可以获取到需要的内容，包含“下一条”，“前一条”，“跳转到某一条”功能；
Player播放功能可以实现自动播放，包括“播放”和“停止”功能；
然后这里抽象出了一个View接口，并且有二个View类实现了该接口(ViewClass1和ViewClass2)，于是接口的render方法就得到了不同的实现，用以呈现不同的UI风格。
这样做有什么好处呢，
首先，我们把各功能拆分出去后，各功能间就得到了解藕，代码间的影响就小了，这样对于代码维护也方便了很多。比如发现自动播放功能有个BUG，可以直接找到Player这个类进行排查修改就行，不用再在一大坨代码里去找半天；
其次，拆分后的代码复用率得到了提高，遇到相似功能的需求时就不用直接COPY代码修改，而是获取现有的功能来使用或封装；
最后，以后有类似需求的扩展，只需要再开发实现View接口的类，配上不同的模板既可，而且不会影响到基础功能。
最后再简单总结一下，做需求开发的时候，先考虑下该功能层面的变与不变的点，然后再跟据单一职责原则进行功能拆分，分离开各独立功能以达到解藕的目的。