C语言的设计模式-接口隔离

C语言的设计模式-接口隔离

接口隔离:

定义为客户端不应该依赖它不需用的接口,在C语言中我们可以把头文件看成一个模块的接口,根据接口隔离原则也就是说这个头文件中只能包含外部需要的接口,但在实际的项目中往往头文件都不符合接口隔离原则。

1:内、外部接口的隔离:头文件中通常包含了模块内部接口(内部类型定义、内部接口声明)和外部接口(外部接口声明)

假设moudle模块对外提供一个fun1接口,模块内部实现需要定义一个结构类型,一般的实现如下:

/*moudle.h*/typedef struct str_s str_t;
struct str_s
{
    int a;
    int b;
};
void fun1();

/*moudle.c*/#include "moudle.h"
void fun1()
{
    str_t s = {0};   TODO...
}

客户端在使用接口的时候需要包含moudle.h文件,而该接口并不符合接口的隔离,其内部包含了客户并不需要的一些定义。为了解决这个问题我们可以通过定义不同的头文件来隔离接口,moudle.h定义外部的接口,moudle.inc定义内部接口

/*moudle.h*/
void fun1();

/*moudle.inc*/typedef struct str_s str_t;
struct str_s
{
    int a;
    int b;
};

/*moudle.c*/
#include "moudle.inc"
void fun1()
{
    str_t s = {0};
   TODO...
}

moudle.h包含外部模块需要的接口,外部模块包含moudle.h,moudle.inc包含内部模块需要的接口,在模块内部包含moudle.inc。通过查看模块的.inc和.h文件,我们就可以清晰的理解模块对外和对内提供了什么接口。

2:避免万能头文件的使用,在实际项目中我们经常可以看到一些头文件包含了所有模块的接口声明,客户端只需要包含这个头文件就可以使用任何接口了。

/*global.h*/
#inlcude "moudle1.h"
#inlcude "moudle2.h"
#inlcude "moudle3.h"
....
#inlcude "moudlen.h"

可能带来如下问题:

会显著的增加编译时间,如果项目大,可能大部分的编译时间都花在展开头文件(笔者一个项目测试80%左右的时间)。

不利于代码的框架的理解,客户端无法从包含的头文件中清晰的看到依赖什么外部模块。

3:如果没有隔离接口可能会导致一些误操作:

一个数据获取模块提供两个接口分别从网络和本地缓存获取数据,后台管理模块使用网络接口定时获取数据更新缓存,前台模块使用缓存接口快速获取数据显示,由于没有对接口隔离,后期的维护人员可能并不清楚开始的设计,在前台模块中直接使用网络接口来获取数据显示,导致界面延迟严重。如果一开始就把接口分离,给前台模块提供本地缓存接口,给后台模块提供网络接口,就不会导致问题的出现。

C语言的设计模式-接口隔离,布布扣,bubuko.com

时间: 2024-10-24 00:52:55

C语言的设计模式-接口隔离的相关文章

小菜学设计模式——接口隔离原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:接口隔离原则 书面理解 接口隔离原则:使用多个小的专门的接口,而不要使用一个大的总接口. 接口应该是内聚的,应该避免"胖"接口.一个类对另

设计模式 接口隔离原则

用类图说明 然后书写代码清单 public interface IPettyGirl{ // 面孔 public void goodLooking(); // 身材 public void niceFigure(); // 气质 public void greatTemperament(); } 接着,使用具体的类实现 public class PettyGirl implements IPettyGirl{ private String name; // 书写名字 public PettyGi

设计模式---接口隔离模式之中介者模式(Mediator)

一:概念 在Mediator模式中,类之间的交互行为被统一放在Mediator的对象中,对象通过Mediator对象同其他对象交互.Mediator对象起到控制器的作用 二:动机 在软件构建的过程中,经常出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系,如果遇到了一些需求的更改,这种直接的引用关系将面临不断的变化.在这种情况下,我们可以使用“中介对象”来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化. 在这种情况下,我们可使用一个“中介对象”

设计模式六大原则(4)--接口隔离原则

定义: 客户端不应该依赖它不需要的接口:类之间的依赖关系应建立在最小的接口之上.接口隔离原则英文全称为Interface Segregation Principle ,简称为ISP. 个人理解: 通俗的来说,接口不能臃肿庞大,而使根据具体需要尽量的细化.接口中的方法也要尽可能的少.接口是设计对外的一种契约,通过分散定义多个接口可以预防将来变更的扩散,使得真个系统变得更加稳定和更具有可维护性. 问题由来: 类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类C不是最小的接口,那么

设计模式六大原则(4):接口隔离原则

接口隔离原则 定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 接口隔离原则(Interface  Segregation Principle, ISP):使用多个专门的接口,而不使用单一的总接口,即客户端

设计模式原则之接口隔离原则

在讲接口隔离原则之前,我们先明确一下我们的主角,什么是接口,接口分为两种: 一种是实例接口 (Object Interface),在 Java 中声明一个类,然后用 new 关键字产生的一个实例,它是对一个类型的事 物描述,这是一种接口,比如你定义个 Person 这个类,然后使用 Person zhangSan = new Person()产生了 一个实例,这个实例要遵从的标准就是 Person 这个类,Person 类就是 zhangSan 的接口,看不懂?不要紧, 那是让 Java 语言浸

设计模式六大原则(4):接口隔离原则(Interface Segregation Principle)

接口隔离原则: 使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变. 定义:

设计模式六大原则: 辅导班的因材施教 -- 接口隔离原则

我的女朋友小肉是一名光荣的辅导班老师,说来惭愧,我上初中那会儿最讨厌辅导班老师了,每天上学都这么累了,晚上还得去见辅导班老师,神烦,奈何目前的教育机制下,很多家长认为辅导班是提高成绩比较靠谱的方式,导致这个行业市场很大. 小肉教三个水平不同的小班,那天看她在准备讲义和试题,同一章内容需要做三份,其中很多内容都是重复的,自诩设计模式略懂一二的我跟她说: 你这个讲义跟我敲代码很像,相似的内容这么多,直接复制粘贴容易出问题啊,还不如把公共的部分提一个接口,然后让三种水平的讲义都实现这个接口 比如这样:

设计模式之禅--六大设计原则之接口隔离原则

设计模式就是让我们更方便的解决问题. 这里分享一个故事.我有一个朋友,嗯没错就是一个朋友,参加一个软件比赛,一个同学写服务器上的代码,三天两头更新,丝毫不考虑写客户端的人的感受,简直不能再牛.如果Java的更新有这么一次,没有考虑在不影响以前代码的基础上做修改,得有多少程序员吐血身亡. 接口隔离原则的定义: 建立单一接口,不要建立臃肿放大的接口.接口尽量细化,同时接口中的方法尽量少. 这不是单一职责原则,单一职责要求的是类和接口的职责单一,注重的是职责,这是业务逻辑上的划分,而借口隔离原则要求接