软件设计模式学习(十六)代理模式

当直接访问某些对象存在问题时,可以通过一个代理对象来间接访问,为了保证客户端使用的透明性,所访问的真实对象与代理对象需要实现相同的接口。 模式动机 某些情况下,一个客户不想或不能直接引用一个对象,此时可以通过一个称之为代理的第三者实现间接引用。代理对象在客户端和目标对象之间起到中介作用,并且可以通过 ... »

微服务架构下的分布式限流方案思考

1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解 ... »

如何用面向对象思想编写代码

一、什么是面向对象 在用面向对象思想写代码之前,先了解一下什么是面向对象? 个人理解: 面向对象:把现实世界里的具体物体或者逻辑世界的逻辑物体,用抽象手段,把这些物体抽象成程序能够识别的类,使类具备物体的属性和行为,把物体与物体之间的关联转换成类与类之间的关联,用编程逻辑把这些关联表示出来设计成程序 ... »

与嵌入式软件开发相关的一些硬件知识

有这么一个问题? 在嵌入式开发中,软件是怎么知道硬件的行为,硬件又是怎样接受软件的操作的。这个问题涉及到硬件和软件相关的知识。要清楚这个问题,需要有一些开发经历才能深入的理解。 一、硬件事件的通知 在设计软件时,需要被告知硬件中发生的事件,事件可以分为两大类: ·一是软件引发的事件,由嵌入式软件下达 ... »

编码最佳实践——依赖注入原则

我们在这个系列的前四篇文章中分别介绍了SOLID原则中的前四个原则,今天来介绍最后一个原则——依赖注入原则。依赖注入(DI)是一个很简单的概念,实现起来也很简单。但是简单却掩盖不了它的重要性,如果没有依赖注入,前面的介绍的SOLID技术原则都不可能实际应用。 控制反转(IoC) 人们在谈论依赖注入的 ... »

编码最佳实践——接口分离原则

接口分离原则 在面向对象编程中,接口是一个非常重要的武器。接口所表达的是客户端代码需求和需求具体实现之间的边界。接口分离原则主张接口应该足够小,大而全的契约(接口)是毫无意义的。 接口分离的原因 将大型接口分割为多个小型接口的原因有: ①需要单独修饰接口 ②客户端需要 ③架构需要 需要单独修饰接口 ... »

编码最佳实践——Liskov替换原则

Liskov替换原则(Liskov Substitution Principle)是一组用于创建 继承层次结构 的指导原则。按照Liskov替换原则创建的继承层次结构中,客户端代码能够放心的使用它的任意类或子类而不担心所期望的行为。 Liskov替换原则定义 如果S是T的子类型,那么所有的T类型的对 ... »

编码最佳实践——开放封闭原则

开放封闭原则定义 开放与封闭原则有两种不同的定义,分别是20世纪80年代最原始的定义和后期一个更现代的定义,后者对前者进行更加详尽的阐述。 Meyer的定义 软件实体应该允许扩展,但禁止修改 ​ ——《面向对象软件构造》 Martin的定义 ”对于扩展是开放的。“ 这意味着模块的行为是可以扩展的。当 ... »

编码最佳实践——单一职责原则

SOLID 是一组 最佳编码实践 的首字母缩写 S 单一职责原则 O 开放与封闭原则 L Liskov(里式)替换原则 I 接口分离原则 D 依赖注入原则 同时应用这些最佳实践,可以提升代码适应变更的能力。但是凡事要有度,过度使用虽然可以让代码有很高的自适应能力,但是会导致层次粒度过小而难以理解或使 ... »

编写日志的正确姿势

一般来说,对于何时写日志并没有明确的限制和约束,只要你觉得记录的日志是有价值的,对跟踪bug是有帮助的,你就可以去添加日志。当然一些敏感信息除外,比如你正在开发一套支付系统,不要把客户的卡号和密码等信息记录在日志中,因为日志并不会被刻意保护,有可能被其他的用户群体收集到。 另外不要担心大量的日志会对 ... »

【模块化那些事】 拆散的模块化

模块化原则倡导利用集中和分解等手法创建高内聚、低耦合的抽象。 为了理解模块化的含义及其很重要的原因,来看看一本书的极端情况。假设一本书像讲一个长故事一样阐述其中的内容,中间没有任何停顿,也没有章节。试问面对这样的图书,读者将作何反应呢?我估计心中一定有千万只草泥马在崩腾吧。如果这本书根据内容分为不同 ... »

【抽象那些事】不必要的抽象

不必要的抽象 在软件设计中引入实际上不需要的抽象时,将导致这种坏味。 为什么不可以有不必要的抽象? 抽象实体应该具有 单一而重要 的职责。如果创建的没必要或是只是为了方便,它们承担的职责微不足道,甚至没有承担任何职责,这违反了抽象原则。 不必要的抽象的潜在原因 使用的是面向对象语言,思维却是过程型编 ... »

【抽象那些事】不完整的抽象&多方面抽象&未用的抽象&重复的抽象

不完整的抽象 抽象未支持所有互补或相关的方法时,将导致这种坏味。 为什么要有完整的抽象? 一种重要的抽象实现手法是创建内聚而完整的抽象。抽象未支持相关的方法时,可能会影响抽象的内聚性和完整性。如果抽象只支持部分相关的方法,其使用者就可能不得不自己去实现其他的功能。客户程序可能尝试直接访问抽象的内部实 ... »

【抽象那些事】 命令式抽象

命令式抽象 这种坏味是由操作转换为类引起的,表现为类中只定义了一个方法,有时候类名和方法名相同。这种坏味还常常表现为方法操作的数据位于另一个类中。 为什么不能命令式抽象? 面向对象的基本原则是,识别真实世界中的事物,并使用抽象来表示它们。在解决方案域中,必须将问题域的对象表示出来,为此可采用 映射域 ... »

【抽象那些事】缺失抽象

抽象原则倡导 通过精简和概括来简化实体 :精简是删除不必要的细节,而概括是找出并定义通用的的重要特征。 这是什么? 这是一个笑脸,那么我们是怎么知道这是一个笑脸的呢?通过抽象。人脸数以亿计,却各不相同。我们忽略了不重要的细节,如发型和发色。我们还概括了相同的东西,每个人都有两只眼睛,微笑时嘴角上扬。 ... »

【关于封装的那些事】 未利用封装

[toc] 未利用封装 客户代码使用显式类型检查(使用一系列if else或switch语句检查对象的类型),而不利用出层次结构内已封装的类型变化时,将导致这种坏味。 为什么要利用封装? 一种臭名昭著的坏味是,在客户代码中使用条件语句(if else或switch语句)来显式地检查类型,并根据类型执 ... »

【关于封装的那些事】 缺失封装

[toc] 缺失封装 没有将实现变化封装在抽象和层次结构中时,将导致这种坏味。 表现形式通常如下: 客户程序与其需要的服务变种紧密耦合,每当需要支持新变种或修改既有变种时,都将影响客户程序。 每当需要在层次结构中支持新变种时,都添加了大量不必要的类,这增加了设计的复杂度。 为什么不能缺失封装? 开闭 ... »

【封装型坏味】 泄露的封装

[toc] 泄露的封装 抽象通过公有接口(方法)暴露或泄露实现细节时,将导致这种坏味。需要注意的是,即使抽象不存在“ "不充分的封装" ”坏味,其公有接口也有可能泄露实现细节。 为什么不能泄露封装? 为实现有效封装,必须将抽象的接口(即抽象的内容)和实现(即抽象的方式)分离。为遵循隐藏原则,必须对客 ... »

【封装型坏味】 不充分的封装

封装原则倡导通过 隐藏抽象的实现细节 和 隐藏变化 等来实现关注点分离和信息隐藏。 以汽车为例,我们并不需要了解发动机的原理就可以开车。这准确描绘了封装原则的作用:用户无需知道抽象(汽车)的细节,此外,封装原则还让抽象能够隐藏实现细节的变化。发动机是汽油发动机还是柴油发动机并不会对我们开车造成影响。 ... »