沉舟侧畔千帆过 病树前头万木春

[设计]软件设计原则这些原则不遵守程序也可以跑的好好的，只是出错的机率大，修改的难度高而已。 1.职责单一原则简单的理解就是一个类只做一件事。 但是生活中到处都是意外。需求改了，有个数划分的更细了。这时我们有多种选择。 1.第一种就是直接改加if 加方法，把这个类改的面目全飞 2.第二种就是只加新方法，让这个类添加新划分的方法来处理。 3.第三种就是重构，代价可能是修改调用者的方法。 优

[设计]抽象工厂模式场景其实也是解决工厂模式的不足。但是不论怎么改工厂的性质是不会变的。所以雷达产品与功能经常性的变化，建议不要采用这样模式。*解决办法添加抽象工厂的抽象接口是不是就可以添加一种产品了添加不同的抽象工厂是不是把实现又向后推了一下，更活性更好了。 我们先创建工厂基本和产品基类 public abstract class FactoryBase {

[设计]建造者模式场景每个雷达都有不同的硬件组成的，可是组成硬件我们不可能一个硬件一个硬件的自己组装，肯定是装好了我们直接来用 简单的说就是我们不会与硬件直接打交道的解决办法很自然的我们想到加一层，加一层抽象层。这样不同的雷达我们只要不同的层（也就是不同的建造者就可以了） 我们先创建产品类，不同的建造者的产品类可能不同这样就不太适合工厂模式，所以说建造者可以很好的应对不同组件的变化pub

[设计]原型模式场景我们有时候要使用不同的雷达对象这样我们就复制一份，这是这样会占很多内存，这时我们可以把这个操作放在要使用之前而不是上来就使用 简单的说就是不到万不得一不要去审请内存解决办法我们可以创建这个对象的原型，如果需要的时候我们把这个对象的另一份副本返回出来由于堆栈的问题可能分为深拷贝和浅拷贝的问题C# 提供了ICloneable这个接口让对象类实现这个接口就可以了我们这里不

[设计]享元模式场景就是一个对象要不停的在用，要不停的复制与拷贝，那这样我们能不能装这个对象不变的部分与变化的部分分开呢 简单的说就是能不能不要保存那么多对象，不要那么多内存，那么这些对象内部状态很多的部分组成解决办法我们要做的把对象分为内外两个部分 我们先创建一些基类public abstract class FlyWeight { public abstra

[设计]外观模式场景雷达客户端要取历史数据和实时数据以及其它的数据，这时如果数据有所更改，也就是服务端更改，客户端也要跟着更改。 我们能不能更改服务而不更改客户端呢？解决办法肯定是可以的，加一层让所有的客户端都与他进行交互所有的一切细节都有这一层来操作外观就是提供一个对外统一的接口 我们先创建两个数据类 class HistoryData { public vo

[设计]备忘录模式场景就是想保存一个对象的内部状态，以方便切换的回来的时候，以恢复到原来的状态解决方法可以导出一个文本文件来分门别类的存放也可以放状态保存到另一个对象中，这个对象专业的用来保存状态我们这里备忘录就是用的第二种方式，而且可以在不破坏被保存对象的内部也不破坏现有的封装。CODE我们新建一个要保存的对象类class Lidar { public st

[设计]状态模式场景有时候一个物体有很多状态，这些状态都是随着某些参数的改变而更改对应的状态，这时你如果用if else 如果一直这样会有很大的逻辑压力，所有这时我们就可以把状态分离出来，我们设计就一个目标把稳定的和多变的分离出来，以降低偶合增强内聚。这时你会想起责任链模式，这里说一下不同的地方，就怕是责任链是调用着或者内部的固定链条，而状态相对责任链是会出现蹦极的可能的，就是不连续的，可以第一

[设计]中介者模式场景就是两个不同类型的雷达要进行交互，如何实现解决办法建立强联系，分别在各自的雷达内部实现另一种雷达的对象，这样就可以通过这个对象来实现。but这种就不能实现代码的复用。这时我们可以考虑加一层来实现，在这一层中我们分别实现不同的雷达的对象，所有的操作我们通过一层来操作来实现，这一层也就是传说中的中介者是不是很有想法，但是这里也说一下缺点。就是这一层要实现的对象，如果有增加

[设计]模版模式场景我们有些操作流程是固定的第一步做什么第二步什么一切都是定的，就像古代的君主一样，生生世世都不变的都东西解决办法我们肯定就是在它一出生就它的流程定下来，对于一个对象一出生也就是它如查不继承别人就是它自己，但是设计依赖了抽象的原则是不能变的。所以我们一般是在它的基类的方法中把流程固化下来还有一点就是要注意，这个方法一定不能被子类重写，不然你懂得，流程就不是固化了最近没有写设

[设计]工厂模式场景就是简单工厂模式每次添加一个雷达都要重新改工厂，万一把工厂改坏了，那不就扯淡了。 要想让一个东西变化的东西稳定就抽象它，抽象才稳定，可是最终还是要实现，所以实现要推到子类中了，只要使用之前实现了原则是推迟都是没有问题。*解决办法如上所说，工厂要稳定，怎么办呢，抽象它。 我们先来一个抽象的工厂基类public abstract class FactoryBase

[设计]简单工厂模式场景能不能有那么一个东西，我进去一个需求出来一个产品，比如我想要一个风雷达，就出来一个可以测风的雷达，我想要一个温雷达，就出来一个测温的雷达。肯定能，自己建个雷达厂，装上个生产线，要什么有什么*解决办法我们这个雷达厂肯定要有对应的生产线，也就是雷达产生的类我们这个这个厂是不是最变化的就是生产线，如果添加一个生产线就能多生产一种雷达，所以我们设计的原则就是把多变易变的东西

[设计]访问者模式场景雷达数据要处理的结果分为很多事，有的要转化为出时空图的数据有的要转化为出地图的数据，有的要转化为出波线图的数据以还要加其它图。 这时数据源不变但是要经过不同的算法出来不同的数据结构 解决办法数据结构是稳定的，操作是变化的那么我就让它们都分离呗，都抽象一下。这样我们在处理数据的类中把操作以参数的形式传进去这样我们就可以来实现两者的关系也就是直接朋友的关系了。这样对我

[设计] 责任链模式场景雷达的数据有时候需要抽析有时候要做一些处理，有时间不要，一句话也就是代码中会出现很多的if else 语句。这时候一但再修改会带来很大的工作量。 常见的写法就是写呗，if else if else … 解决办法我们把所有的不同条件下的处理都分布到不同的类中，那样我们如果添加条件也就是添加一个类这样就符全设计原则了。 我们要先确定一下条件处理的对像类也就是请求处理的对象

[设计]策略模式场景雷达每次都有很多的通道，但是每个通道的数据和展示是不太一样的，这样就会形成很多的ifelse switch case 等。所以我们想能不能把所有的通道都封装成一个类呢。答案肯定是可以的。这样我们每次只要切换不能的通道调用不同的类就可以了。 简单的也就是说各个通道的地位是平等的可以互换的。 解决办法我们定义一系列的类来表示各个通道。我们让调用者依赖于这个类的一个抽象父类

[设计]桥接模式场景我们有很多雷达，所有的产品基本都是差不多的，但是具体的实现细节不太一样，这时如果采用继承，每个雷达子类中都会有很多相同的代码，而且如果修改了父类，所有的子类都要修改。 其实细心就会发现违背了单一职责和开闭原则。最至命的是扩展性太差了。搞的每次一个小功能基本都要把代码重写一遍的精力。 你可能想到可以把抽像与实现分离啊 解决办法我们把抽像与实现分离开来。使雷达和功能在各自的

装饰者模式场景不同的雷达有不同的功能但是大部分都相同，如查用继承就会写很多相同的代码，而且功能和雷达之间是偶合关系强，迁一发而动全身。 你可以想到类似的场景如:不同的电脑有不同的配置等等 解决方法如果雷达能动态的添加或者去除某些功能是不是就ok了。 但是功能只能适用于雷达，肯定还要与雷达建立关系所以我们提出一个父类 然后建立朋友关系（以参数传递） public abstrac

[设计]观察者模式场景有很多客户端不定的会连接交互模块，也不知道何时退出，要实现连接上就进行消息推送，不连接就不推送。 简单的办法找一个集合来记录所有的对象，如果来消息就扫一遍这个集合，然后执行对应的操作。 解决办法能实现让这个记动权放在客户端手里吗？能够依赖于抽象吗？每次观察者都能得到信息吗？c# 提供了委托和事件，你要这就是封好的模式，委托不就是一个抽象的观察者吗？ 我们先创建一

[设计]命令模式场景要保存数据到文件。但是服务提示的接口有顺序的要求 那就 一个挨着一个的调用呗，正确，可是在应用中多线程的情况下，乱的给那什么啊？什么，麻绳。 解决办法传之前排好顺序一下传过去。当然如果有问题不是加一层可以解决的，那就加两层这个小问题应该加一层就可以了。让命令的发出者的执行者分开。让命令类，发生类，执行类都有自己的抽象类，抽象更稳定，此处只抽了命令，以做演示。 我们

[设计]适配器模式场景雷达数据是从服务端传过来的，但是历史和实时的数据结构不太一样，但是这样操作数据要么重载但是处理过程基本一样，所以这时间每个都写两个方法维护成本太高 所以这里想把实时数据适配成历史的解决方法可以让实时和历史都继承自同一个父类，C# 不支持多继承所以可能要用接口，这是继承这种强聚合关系也会使后期的维护成本提高。也就是传说中的类适配的方式。这里不采用所以这里采用对象适配的

[设计]组合模式场景每个雷达功能很多，可是现在要做一个雷达平台就要与多个服务相连接获取数据。 简单的办法：肯定是new 多个连接对象，各人连各人的。但是这样容易造成有的个雷达某些功能忘记掉用了，添加一个功能要改多处，人非硬盘怎能不忘 解决办法我们能不能不论单个还是多个都能一样的操作来处理呢？肯定是可以的，所有的都依赖于抽象这样不就可以达到了吗多个雷达特有的功能，我们要不要定义在抽象类中呢

[设计] 代理模式场景一个对象没有能力和权限要做一件事，但是另一个对象却有。有一个需求如下一台温雷达客户端可以连温雷达的服务，可是它不能连风雷达的服务，这个时候它想连接风雷达的服务取数据怎么办呢？解决方案方法就是模拟一个风雷达的客户端的操作，但是问题是谁来模拟怎么模拟。 一种就是直接模拟，在需要的地方地方都新建一个风雷达的对象，但是这样的硬编码可能造成混乱比如风雷达和温雷达的逻辑操作的混乱