浅度学习模块化与解耦

目录

1、为什么要模块化

2、模块设计原则

3、模块化开发的的优缺点

4、解耦与通信

4.1 公共模块的下层

4.2 面向接口调用

4.3 面向协议的调用


 

在开篇之前引用一句话:

一派是说app开发并不需要什么狗P架构,第二派说我们有自己NB的架构,第三派说只要模块化够好,每个模块应该有自己的架构。

 

Ricardo.M.Tan:

作为初学者,在这里借鉴他人经验与总结自己过往的编码历程,分享一些浅度的模块化设计与解耦经验,当然,现在的观念任然可能会被以后的观念所覆盖,因为我一直致力于更新自己。

 

1、为什么要模块化


  • 代码设计原则:“Don`t repeat yourself.” ,避免重复造轮子。
  • 每个程序设计都应当有自己的架构
  • 通常单独的代码应当拿出来,做成单独的模块,提高模块的复用性。

2、模块设计原则


  • 越底层的模块,应该越稳定,越抽象,越具有高度复用性。
  • 不要让稳定的模块依赖不稳定的模块,减少依赖。

例如:B模块依赖A模块,但是B稳定而A不稳定,这样B模块也会变得不稳定。

怎么办?最好不要依赖。但如果B确实必须依赖A怎么办?提出A中B依赖的代码块X,单独建一个模块。但如果X是一个方法或者函数怎么办?将X拷贝至B模块中,曾强B的稳定性和完备性。都不行怎么办?解耦。

  • 提升模块的复用度,自完备性优于代码复用性。

 自完备性指什么?就是尽可能的减少模块间的依赖,来提高代码的可复用性。

在平时的设计中,我们会依赖某些模块中的方法,例如Math函数中的各种方法,但是在设计更为基础的模块时,不适合再引用,这样会产生依赖。应当自己重新去实现这些方法。

  • 每个模块只做一件事,不要让Common出现 。

 模块结构的设计是为了让代码更具可读性,设计结构更清晰。每个模块只做一件事便于良性发展,如同一个人在一个团队中,分工明确最合适,因为这样精力最集中,运行与维护的效率更高。

当然,在一个设计中,一个模块的工作几乎穿插了整个设计,如同团队中的Leader,他们要胜任更多的事务。但这样的模块设计并不一定合适,假如假以时日,Leader处理能力越强,能担任的事务越多,那么将他放到那个部门最合适呢?这也说明如果某个模块实现的功能越多,日积月累,他就越“冗杂”,越庞大,那它相对于其他的模块来说会形成高度的被依赖,这样会产生耦合,不稳定。模块的复用性会变差。平时应当将某些功能的实现单独建块。

  • 按照自己的结构设计,从上到下,不要出现下层模块依赖上层模块的现象,或者尽可能的去避免。
  • 业务模块之间尽量不要耦合。

3、模块化开发的的优缺点


在这一类问题上,我可能知之甚少,毕竟做开发的时间还不及前辈已写的一篇文章的存在的时间长。

优点:

1、模块代码复用性

2、功能复用

3、业务逻辑隔离

4、符合封装性与合理性的要求

缺点:

1、门槛高

2、使得开发成本与效率成反比,毕竟团队中模块的开发与使用需要通过成员交流

无论怎么说,在整体上来看,后期的利大于弊。

4、解耦与通信


这里要叙述的东西实在过多,概念也较为复杂,尽量都说清楚。

为什么要解耦?

模块化并不只是将设计分块,分成多个代码块就行的,真正的模块化是实现模块之间真正的解耦,否则模块之间还是会互相调用,产生循环依赖。

模块解耦的目标是在基于模块设计的原则上,让模块之间没有循环依赖,让业务模块之间解除依赖。

4.1 公共模块的下层

 开发的过程中,不注意很容易发生处于较底层的模块依赖了上层的模块,这种情况下应该对模块的设计进行改造实现单向依赖。

4.2 面向接口调用

虽然说公共模块可以通过架构设计来避免耦合业务,但是业务模块之间还是会有耦合的啊,而且这种情况是最多的,比如页面跳转啊,数据传递啊,这些情况前面的方法已经不够用了。那如何解耦不同业务模块之间的代码调用呢?

那就是面向接口调用。

直接调用方法会产生依赖,例如:

// A 模块
(void)getSomeDataFromB {
       B.getSomeData();
}
// B 模块
(void)getSomeData {
       return self.data;
}

那么我们可以实现一个 getSomeDataFromB 的接口,让 A 只依赖这个接口,而 B 来实现这个接口,这样就实现了 A 与 B 的解耦。

// 接口
(void)getSomeData;


// A 模块, 只依赖接口
(void)getSomeDataFromB {
     int i=new B().getSomeData;
}


// B 模块,实现BService接口
(void)getSomeData {
     return self.data;
}

 这样就可以实现了即满足了模块之间调用,也实现了解耦。接口类似代码,可以非常灵活的定义函数和回调等。可是接口定义文件需要放在一个模块以供依赖,但是这个模块不会贡献代码,这点还好。麻烦的是每各调用都需要定义实现接口的方法,并实现, 对于一些具有普适性规律的场景不太合适。

4.3 面向协议的调用

面向接口调用的缺点导致并不能满足所有的需求,也解耦的不够彻底,可以通过定义一套协议来实现模块间的通信,协议可以是现成的,如URL跳转协议,这就是通信

猜你喜欢

转载自blog.csdn.net/ricardomtan/article/details/81087412