crylearner的专栏

作为设计模式推演的序章，我们以一本书中的例子为序：我们有一些基本的设计原则， 复用+易用，         有OO 5P设计原则:  ISP 接口隔离原则， LSP里氏替换原则，OCP 开闭原则，SRP单一职责原则， DIP抽象依赖倒置原则我们也有OO工具，封装，继承，多态最后也有基本的设计模式，各种工厂方法，Command模式等下面我们以数学中的代数为例子，介绍一下这

开局篇我们说了，RPC框架的四个核心内容:RPC数据的传输, RPC消息协议, RPC服务注册, RPC消息处理。接下来处理RPC服务的注册机制。所谓注册机制，就是Server需要声明支持哪些rpc方法，然后当客户端发送调用某个声明的rpc方法之后，服务端能自动找到执行该请求的具体方法。1. 引入服务注册的方式也是为了代码解耦，将req的处理与具体的req消息内容解耦。2. 上面我们 引入了两种服务注册的方式，一种方式是普通的方式，逐个添加方法。另一种方式通过python的“反射”技术，自动查找一个服务

之前我们制定了一个很简单的RPC消息 的格式，但没有实现相应的encode和decode方法，下面我们处理掉这个编解码问题。这里我还是简单原则，重点在于晓义嘛。利用python里的两个运算。 str 和eval，实现编解码。

上一篇，我们制定了一个很简单的RPC消息 的格式，但是还遗留了两个问题我们并没有实现相应的encode和decode方法，没有基于可以跨设备的字符串传输，而是直接的内存变量传递。现在的RPC request不支持带参数的请求命令。如add(a, b), 如何在RPC消息中描述参数a,b 。我先来实现第二个问题，即带参数的RPC调用。其实，也没什么太大不同。既然是要带参数，那

开局篇我们说了，RPC框架的四个核心内容RPC数据的传输。RPC消息 协议RPC服务注册RPC消息处理下面，我们先看一个普通的过程调用class Client(object): def __init__(self): self.remote = None ## # 内部是委托给远程remote对象来获取结果。

开场白，这是一个关于RPC的相关概念的普及篇系列，主要是通过一步步的调整，提炼出一个相对完整的RPC框架。RPC（Remote Procedure Call Protocol）——远程过程调用协议，基于C/S模型。有四个核心内容：RPC数据的传输，RPC消息的表示与编解码，RPC服务注册，RPC消息的任务处理机。这个RPC框架的搭建，庄稼人将采用python作为开发语言，是从原始的普通调用开始，然后一步步的演化，最后生成一个完整的Rpc框架

上一篇文章中，我们提到OO中复用的方式有两种，组合和继承。一般情况下，应该尽可能使用组合的方式。现在以复用为基本需求，推演若干常见组合型模式1. Facade模式 当整合已有系统接口时，或者跨层调用接口时，如果出现a. 觉得接口过多。那么可以根据特定的应用情景，提炼出一个最小覆盖子集，或者只是最常用的接口集。b. 觉得接口难用。那么可以通过封装，对原来做一些变形。这就是

上一篇文章中，我们提到OO中复用的方式有两种，组合和继承。一般情况下，应该尽可能使用组合的方式。现在以复用为基本需求，推演若干常见组合型模式1. Decorator模式 需求：我们已经有一群对象，现在想统一为这些对象添加若干新特性。更重要的是，这些新特性可以反复叠加于某个对象，或者只选择部分特性作用于某个对象。条件：如果这个特性的实现不依赖于具体的对象，就如同添加一个装

OO中，复用代码可以有组合和继承两种方式，正如广大人民群众所论述的，尽可能使用组合。这里我再不厌其烦的说明一下理由：1. 组合比继承在框架结构上要简单，不会造成过深的继承层次。2. 组合是黑盒重用，抽象层次更高。其实上面这两条我觉得也没啥，重点还是下面三条：3.组合可以在运行时动态选择复用的对象，而继承不行。直接上图，相信您看一眼就明白了当Stack复用Sequen

上一篇文章中提到，在做代码设计时，坚持OCP原则，坚持一起从需求分析开始，分析当前代码中哪些是不变的，哪些是变化的，那么我们就可以做到简单而快速的响应客户需求。现在，我们来讨论创建型模式还是从需求分析开始，使用创建型模式，实际是为了将类名和类的创建解耦。换成变与不变的说法就是，产品名称可能经常发生变化或者有扩充，但是这些产品对象的使用方式不变。假设我们现在有产品类Wall（A，B，

客户需求分析，实际上就是分析需求是否可以实现、需要修改哪些地方。理想情况下，我们的产品应该是对已有部分不做任何修改，而只是对新的需求做一些扩展，这就要求我们在设计时遵循开闭原则。事实上，需求分析贯穿于整个编码活动中，因为当代码之间相互协作时，一部分代码就是另一部分的客户。         开闭原则分为两部分，对修改关闭，对扩展开放。在OO语言下，对修改关闭，一般可以应用继承，使各需求共

开局篇我们说了，RPC框架的四个核心内容RPC数据的传输。RPC消息 协议RPC服务注册RPC消息处理   接下来处理数据传输。实际应用场景一般都是基于socket。socket代码比较多，使用起来也比较麻烦。而且具体的传输通道使用socket或者其他的方式，如更上层的http，或者android里的binder，都是可替换的，只是具体的一种实现而已。所以，这里我就偷个懒，只是