dongnihao的博客

面对这种需要根据不同客户使用不同接口的情况，一个常见的解决方案是使用。策略模式允许在运行时选择算法或行为，非常适合于你描述的场景，即根据不同的客户使用不同的发送短信接口。

实际工作中出现的场景是，产品经理和领域专家沟通后，未与研发达成“通用语言”的同步，导致对同一“模型”的理解偏差，（这边的“模型”，不仅指数据的抽象，更多指代业务的抽象）。

同样的，替换模板的生成也不应该关注R的业务，根据R定义的DTO/Entity 来动态生成的对应的XML。简单理解为： R项目 调用了 E项目的打印接口，但是E项目需要对R传来对数据传输对象DTO进行二次处理，甚至夹杂很多R项目的业务逻辑（去调用R项目的接口），经过多个迭代以后，R项目和E项目的接口对接人已经成为了相亲相爱一家人👨‍👩‍👧‍👧。从代码层面来说，E应该只定义接口的规范，具体的实现让R来做，比如打印类的定义可以直接继承自R项目的DTO，这样不会因为业务的频繁变动而导致对接人的工作量增加。

近期有些tasks需要 重构or适配 老的代码。与其向上面堆💩，不如优雅的去解决。总之，时间足够我就优雅的，完美的去建立一个可扩展性强的适配层。如果催我。那我就堆堆乐 💩💩💩

简单理解，就是将一段60min的影片，切片为30份，每份两分钟，形成“串流”，那么当你跳到40分钟的时候，影片不需要加载完前39分钟的内容，而是找到与之相邻的最近的一块切片，也就是“一段流”，直接下载这段流，节约时间和资源 。在解决同步异步的问题上，ReactiveX对于任何发生的事件都当作串流（stream）网页上的鼠标点击事件就是一连串时间的串流，除非网页关闭，否则这个时间就是会持续发生的。 同理，HTTP请求也是一个串流，只不过这种串流只发生一次。再甚至是处理一个数组，可以将数组的每个元素想成串流的一

精读DDD，今天再次理解一下service，概念以及应用到实际工作中出现的一些错误。

今天在翻设计模式，火鸡鸭子嘎嘎叫。原来我一直在用外观模式，一不小心还用成了上帝模式 😂这种模式比较简单，不贴伪代码了是一种结构型设计模式， 能为程序库、 框架或其他复杂类提供一个简单的接口。简单粗暴理解：A( ) B( ) C(A( )B( ))外观类为包含许多活动部件的复杂子系统提供一个简单的接口。与直接调用子系统相比， 外观提供的功能可能比较有限， 但它却包含了客户端真正关心的功能。举个例子： “小爱同学，我要看电视”。然后小爱就打开电视，打开暖气，打开氛围灯。。。

类的代码行数越多， 弄清其运作方式就越困难， 对其进行修改所花费的时间就越长。一个功能上的变化可能需要在整个类范围内进行修改， 而且常常会产生错误， 甚至还会有一些严重的副作用。当然并不是说一定要实现这一点， 桥接模式可替换抽象部分中的实现对象， 具体操作就和给成员变量赋新值一样简单。例如， 基础遥控器可能只有两个按钮， 但你可在其基础上扩展新功能， 比如额外的一节电池或一块触摸屏。记住， 设计模式并不仅是一种对类进行组织的方式， 它还能用于沟通意图和解决问题。你可以开发独立于设备类的遥控器类。

Teamleader常见的提醒句式：“你调xxx方法时候先调保存方法”或许 命令模式+TypeScript 能解决这个问题？常用的解决方案是MVC命令模式建议 GUI 对象不直接。你应该将请求的所有细节 （例如调用的对象、 方法名称和参数列表） 抽取出来组成命令， 该类中仅包含一个用于触发请求的方法。命令对象负责连接不同的 GUI 和业务逻辑对象。此后， GUI 对象无需了解业务逻辑对象是否获得了请求， 也无需了解其对请求进行处理的方式。

存在服务器的某处，我们俩从不同的入口访问了而已。是一种结构型设计模式， 它摒弃了在每个对象中保存所有数据的方式， 通过共享多个对象所共有的相同状态， 让你能在有限的内存容量中载入更多对象。讲讲这个细粒度是什么，指的是你看片的时候，时间，入口，设备可能是不一样的，但是片本身的资源是固定的，这个就是细粒度。外部状态指的是动态变化的参数（看片的时候，时间，入口，设备），内部状态是不变的（片本身的资源是固定的）2.享元工厂（维护享元对象的池子）

是一种行为设计模式， 让你能在不暴露集合底层表现形式 （列表、 栈和树等） 的情况下遍历集合中所有的元素。你计划在罗马游览数天， 参观所有主要的旅游景点。但在到达目的地后， 你可能会浪费很多时间绕圈子， 甚至找不到罗马斗兽场在哪里。或者你可以购买一款智能手机上的虚拟导游程序。这款程序非常智能而且价格不贵， 你想在景点待多久都可以。第三种选择是用部分旅行预算雇佣一位对城市了如指掌的当地向导。向导能根据你的喜好来安排行程， 为你介绍每个景点并讲述许多激动人心的故事。

首先状态模式，我在工作中前端看的比较多，可能是因为同事都是大佬，搞后端的顺手搞搞前端。简单来说：就是电商场景，加入购物车，下单，不同用户对应不同的状态。举个超简单🌰例子，又叫做状态机模式。1) 行为随状态改变而改变的场景。，并且这些分支取决于对象的状态。2) 一个操作中含有庞大的多。

可以看到以上的场景是一个多链条的处理，不在像前面的单链条模式，在处理以上结构时，我们的策略往往都是责任链的变种处理：管道模式处理。管道模式的处理大致上就正好如同以上的处理流程图一样。自己的理解：公司的OA流程，我要请病假，告诉了组长，组长说我知道了，然后交给了部门经理，部门经理知道了批完，转给了总裁，总裁说你滚吧 n+1 😊。二是需要关注处理顺序，按责任链条延续处理，每个处理节点均可对请求进行节点的处理， 或将其传递给链上的下个处理节点；一是无需太关心责任链中各处理流的顺序的简单使用；

如果是工厂模式或者抽象工厂模式，会出现“超级构造器” 这种离谱的东西，所以我们将构造交给一个 叫做 “builder” 的内部类，返回的还是原属性，对原属性进行set。想想自己做前端的时候就出现了这个问题，随着需求的变化，之前的函数可能只要3个穿参数，后来就变成十几个参数。tips：.net 中使用builder pattern时候，应该是有很多便捷方法的，特性应该是可以实现的。这个用的时候自己看一下。看代码部分，JAVA的实现，写了一个内部类，获取的值返回给原属性。那么在调用的时候，可以使用。

DDD：根据领域划分业务，领域可以无限大或者无限小，这取决于业务分析师（产品经理和技术专家）看一下DDD的分层架构，是多层的，单向的，可以跨级访问的。理解一下：你平常做的任何继承接口的实现，都是在做防腐层的事情，举个例子，某一天你的验证码服务商换掉啦，只需要重新实现其对应接口。外层的代码只能调用内层的代码，内层的代码可以通过依赖注入的形式来间接调用外层的代码。依赖关系是单向的，所以下一层中的代码不能使用上一层中的逻辑。1、内层的部分比外层的部分更加的抽象→内层表达抽象，外层表达实现。

有一说一DDD真tM抽象 :

虽然两者实现的功能一样，但是代码设计上的是被秒成渣。自己做就是直接干，贫血模型一干到底，业务给domain，甚至全给application service。别人做就是充血模型，优雅。学习这个东西是这么一回事，打工这么久，有些时候是在把别人做过的东西按自己想法实现一遍。之前做上传三方报告的需求时候，其实别人已经做过上传诊断报告的需求了。重点复习一下特征2的原理。...

所以，我们：事务的提供往往是由数据库管理程序来提供的，而这一类组件我们一般将它们放置在基础构架层，而领域层可以依赖于基础构架层，所以千万要注意，保持您的领域层足够干净，不要让其它的东西干扰它，也更不要将事务处理这类东西放到了您的领域层来。...

学习这章的原因：实际工作项目中有些实体内写了方法有些只是纯粹的属性定义。正好领域驱动设计看到了贫血和充血模型。记录一下。说实话虽然敏捷开发中大家不太关心你的功能设计背后的结构逻辑，但是本着对自己负责的态度，这部分需要。插一句：充血模型最大的困难是如何映射到数据库，这边需要看一下杨中科P165之后的教程。1、贫血模型：一个类中只有属性或者成员变量，没有方法。2、充血模型：一个类中既有属性、成员变量，也有方法。举个🌰栗子：需求：定义一个类保存用户的用户名、密码、积分；用户必须具有用户名；......

git pull 后不加参数的时候，跟git push 一样，默认就是git pull origin 当前分支名。本地master分支执行git pull的时候，其实就是git pull origin master。git pull 等效于先执行 git fetch origin 当前分支名, 再执行 git merge FETCH_HEAD.git pull操作其实是git fetch 与 git merge 两个命令的集合。问题场景：在远程代码仓库新建了一个分支，本地想直接切到这个分支发现无法找到。.

分部类和方法 - C# 编程指南 | Microsoft DocsC# 中的分部类和方法拆分一个类、一个结构、一个接口或一个方法的定义到两个或更多的源文件中。https://docs.microsoft.com/zh-cn/dotnet/csharp/programming-guide/classes-and-structs/partial-classes-and-methods在 C# 语言中提供了一个部分类，正如字面上的意思，它用于表示一个类中的一部分。一个类可以由多个部分类构成，定义部分类的语法形

今天补基础时候看见：好像很久很久之前team leader和我讲过把巴拉巴拉抽成工具类会好一些，现在想想其实自己写了很多"工具类",但是都么有按照规范来。今天索性写个博客规范一下。一般直接通过类名调用，比如Math.pow 落实到具体项目里的话，建议另外建一个叫做Utils 文件夹。 如何保证一个工具类不能被实例化呢？私有化private其构造器至于不这样做行不行，当然是可以的，正常人使用工具类也不会想去实例化。写这个主要目的是规范化，并且告诉未来的自己，这他🐎是个工具类。那么问题来了,一定要.

定制化开发撸久了，会很明显的感觉到都是在别人的 “基建”下干活，灵活度受限。这种感觉想了想应该是来自于设计模式的问题，很多东西都是前人给你设计好的（super class），自己开干的时候要么按部就班要么直接推翻重来。业务太复杂根本没时间从头梳理，而且有时候辛辛苦苦想好想好的设计模式，产品发个神经扔个离谱的需求来，全部白干。所以决定从头开始把设计模式过一遍，可以不落地，但是我不能不会，至少写代码时候能想到一种以上的的模式来尝试。----------------------------------------