接着前几期关于嵌入式软件框架
框架设计中的常用模式
模板方法模式
模板方法模式是框架中最常用的设计模式。其根本的思维是将算法由框架固定，而将算法中详细的操作交给二次开发者达到。例如一个设备初始化的逻辑，框架代码如下：
DownloadFPGA和InitKeyPad都是CBaseDevice定义的虚函数，二次开发者创建一个继承于CBaseDevice的子类，详细来达到这两个接口。框架定义了调用的次序和错误的处理方式，二次开发者没须关怀，也没权决定。
文章相对比较长，字数比较多，大家可以先打开头像关注我，之后慢慢看，///插播一条：我自己在今年年初录制了一套还比较系统的入门单片机教程，想要的同学找我拿就行了免費的，私信我就可以哦~点我头像左下角黑色字体加我也能领取哦。最近比较闲，带做毕设，带学生参加省级或以上比赛///
创建型模式
由于框架通常都波及到各种不同子类对象的创建，创建型模式是经常运用的。例如一个绘图软件的框架，有一个基类定义了图形对象的接口，基于它能够派生出椭圆，矩形，直线各种子类。当用户绘制一个图形时，框架就要实例化该子类。这时候能够用工厂方法，原型方法等等。
音讯订阅模式
音讯订阅模式是最常用的别离数据和界面的方式。界面开发者只须要注册须要的数据，当数据变化时框架就会将数据“推”到界面。界面开发者能够没须关注数据的来源和内部组织形式。
音讯订阅模式最常见的问题是同步模式下怎么样处理重入和超时。作为框架设计者，一定要考虑好这个问题。所谓重入，是二次开发者在音讯的回调函数中执行订阅/取消订阅的操作，这会破坏音讯订阅的机制。所谓超时是指二次开发者的音讯回调函数处理时长过长，导致其他音讯没法响应。最简略的办法是运用异步模式，让订阅者和数据发布者在独立进程/线程中运行。假如不具备此条件，则必需作为框架的重要约定，禁二次开发者产生此类问题。
装饰器模式
装饰器模式赋予了框架在后期增加功能的才能。框架定义装饰器的抽象基类，而由详细的达到者达到，动态地添加到框架中。
举一个游戏中的例子，图形绘制引擎是一个独立的模块，假如能够绘制人物的静止，跑动等图像。假如策划决定在游戏中增加一种叫“隐身衣”的道具，要求穿着此道具的玩家在屏幕上显示的是若有若没的半透明图像。应该怎么样设计图像引擎来适应后期的游戏升级呢？
当隐身衣被装备后，就向图像引擎添加一个过滤器。这是个极度简化的例子，现实中的游戏引擎要比这个复杂。装饰器模式还常见用于数据的前置和后置处理上。
框架的缺少点
一个好的框架能够大大提高产品的开发效率和质量，但也有它的缺少点。
1.框架一般都比较复杂，设计和达到一个好的框架须要相当的时长。所以，一般独有在框架能够被屡次反复应用的时候合适，这时候，前提投入的老本会得到丰厚的回报。
2.框架规定了一系列的接口和规则，这虽然简化了二次开发工作，但同时也要求二次开发者必需记住很多规定，假如违反了这些规定，就不能正常工作。但是由于框架屏蔽了大量的领域细节，相对而言，其进修老本还是大大降低了的。
3.框架的升级对已有产品可能会造成严重的影响，导致须要完整的回归测试。对这个问题有两个办法。第一是对框架自身进行严格的测试，有必要建设完善的单元测试库，同时开发示例项目，拿来测试框架的所有功能。第二则是运用静态链接，让已有产品不轻易跟随升级。当然，假如已有产品有较好的回归测试伎俩，就更好。
4.性能损失。由于框架对系统进行了抽象，增加了系统的复杂性。诸如多态这样的伎俩运用也会普遍的降低系统的性能。但是从整体上来看，框架能够保证系统的性能处于一个较高的水平。
对单片机感兴趣的朋友可以找我，我录制了一些关于单片机的入门教程，有需要的童鞋找我拿就像，免费的，私信我“林老师”就可以拿～点击打开我的头像就能领取。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。