低耦合-潍坊IT培训负责整理
耦合指的是模块之间存在依赖关系,关系相互依赖就会相互制衡,这是必然的.所以,如果耦合度太高的话,将会导致牵一发而动全身的后果,这个使我们不想看到的,也极大的影响的程序版本的迭代以及bug的修复.根据依赖关系的不同,我们分为了非直接耦合、数据耦合、内容耦合、开关耦合、控制耦合、外部耦合等等.我们要完成一个系统的开发,必须要将各个模块有效的组织起来,这种组织关系便无法避免存在了耦合,我们要做的是尽量减少这些依赖关系,尤其避免交叉依赖,将耦合度降低到最低,把我们的程序设计的更加的灵活.
适度设计
我们在设计的时候如果考虑不周,那么设计不够,不能满足现有或者可预知的需求,从发展的眼光来看,会导致后期的开发中出现很多的问题.如果想的太多,很容易进行过度的设计,从而将一个简单的系统设计的很复杂,那么就给当前的开发将增加了许多无意义的工作,降低了开发效率.那么怎样的设计才是合理的设计呢?我认为能够同时满足现有的需求和可预知的需求,并且面对架构的调整时能够很方便的进行扩展.这样的设计,是非常好的设计.如何才能达到这样的效果呢?我个人觉得在对系统进行设计时,关注点分离的颗粒度需要把握好,系统不过就是将不同单一小模块进行组织而已,那么这些细小的模块就是架构设计的基础,这就好比建房的那些砖头.这些砖头是什么呢?他么可以是是一个对外提供接口的公共方法,也可以是私有的内部方法,也可以是某某持用的成员变量.当然往大里看,他可以是某一个功能模块.在上述行业内各个app的架构演进中,都很强调进行模块化的改造.所以,分离好你的系统,才能够灵活的组织起来,以不变应万变.
(4)、设计方案
指导模型
下图在文中已经提到,这里再次引入,因为这张图对我的启发真的很大,也表达出了我心之所想.面对一个复杂的系统,我们怎么样去分离,怎么样去组织,我认为这张图已经传达出了其中的精髓,所以我认为这是架构设计的指导模型,无论你是什么MVC、MVP、MVVM之类的,都可以从中去理解.
横向分块
根据上图的简化模型,我们可以这么理解,在横向我们根据业务功能进行模块划分.比如主题商店,我们可以分为壁纸、铃声等等模块,每个模块间解耦.同时,在每一层的业务间再次进行分块,比如壁纸在数据层就有图片的请求、加载、缓存、裁剪处理等等.
纵向分层
接下来我们在对每个模块的业务根据职责分为展现层、业务层、数据层.数据层主要负责数据的获取、封装等工作,业务层主要更加上层的需要调配各数据层最终将数据返回给展现层,展现层的工作就是将数据展现在UI界面上,并且响应人的各种指令切换UI,操作新的数据.
接口通信
在横向来看,我们将业务进行了分块,保证块与块之间相互之间没有任何依赖,保证了绝对的解耦.从纵向来看,每个层级之间的依赖很明显是无法避免的,所以我们可以保证上层仅依赖下层的接口,从而达到降低其耦合度的目的.
当然,这是一个理想的模型.在我们的实际开发中可能无法避免一些交叉等特殊情况,我们还需要从实际情况出发.但是有一点,我们可以保证接口的分离,已达到更低的耦合度的目的.
以上就是潍坊IT培训给大家做的内容详解,更多关于IT知识的学习,请继续关注潍坊IT培训