Observer

　　 说到观察者模式，在我脑海中总是闪现，这家伙跟消息队列的主题发布订阅有什么关系，虽然本人对消息队列没有很深的研究，但是凭直觉我就认为消息队列的实现就使用了观察者模式吧，所以本文就来模拟消息队列的丐版实现阐述观察者模式是怎样玩的。 观察者模式的GOF官方解释是： 定义对象间的一种一对多（变化）的依赖关系， 以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并更新。 　　观察者模式类图如下： 　　 主要构成就是主题基类， 观察者基类及其他们的实现。接下来我们开始设计属于我们自己的消息队列。 01、 首先设计主题基类 from abc import ABC class Subject(ABC): def __init__ (self): self.observers = list() def add_observer(self, observer): self.observers.append(observer) def pop_observer(self, observer): self.observers.remove(observer) def notify(self): for observer in self.observers: observer.update() 在Subject基类中，我们需要定义一个观察者列表用于盛放观察者对象

一、定义 　　设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是 为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。 二、产生背景 　　肯特·贝克和沃德·坎宁安在1987年利用克里斯托佛·亚历山大在建筑设计领域里的思想开发了设计模式并把此思想应用在Smalltalk中的图形用户接口的生成中。一年后Erich Gamma在他的苏黎世大学博士毕业论文中开始尝试把这种思想改写为适用于软件开发。与此同时James Coplien 在1989年至1991 年也在利用相同的思想致力于C++的开发，而后于1991年发表了他的著作Advanced C++ Idioms。就在这一年Erich Gamma 得到了博士学位，然后去了美国，在那与Richard Helm, Ralph Johnson ,John Vlissides合作出版了Design Patterns - Elements of Reusable Object-Oriented Software 一书，在此书中共收录了23个设计模式。这四位作者在软件开发领域里也以他们的匿名著称Gang of Four(四人帮，简称GoF),并且是他们在此书中的协作导致了软件设计模式的突破。有时这个匿名GoF也会用于指代前面提到的那本书。 三、学习的意义 　　设计模式的本质是面向

什么是设计模式 ​ 要了解设计模式，首先得清楚什么是模式。什么是模式？模式即解决一类问题的方法论，简单得来说，就是将解决某类问题的方法归纳总结到理论高度，就形成了模式。 ​ 设计模式就是将代码设计经验归纳总结到理论高度而形成的。其目的就在于：1）可重用代码，2）让代码更容易为他人理解，3）保证代码的可靠性。 ​ 使用面向对象的语言很容易，但是做到面向对象却很难。更多人用的是面向对象的语言写出结构化的代码，想想自己编写的代码有多少是不用修改源码可以真正实现重用，或者可以实现拿来主义。这是一件很正常的事，我在学习过程当中，老师们总是在说c到c++的面向对象是一种巨大的进步，面向对象也是极为难以理解的存在；而在开始的学习过程中，我发现c++和c好像差别也不大，不就是多了一个类和对象吗？但随着愈发深入的学习使我发现，事实并不是那么简单，老师们举例时总是喜欢用到简单的对象群体，比如：人，再到男人、女人，再到拥有具体家庭身份的父亲、母亲、孩子。用这些来说明类、对象、继承......似乎都显得面向对象是一件轻而易举的事。 ​ 但事实真是如此吗？封装、粒度、依赖关系、灵活性、性能、演化、复用等等，当这些在一个系统当中交错相连，互相耦合，甚至有些东西还互相冲突时，你会发现自己可能连将系统对象化都是那么的困难。 ​ 而在解决这些问题的过程当中，也就慢慢形成了一套被反复使用、为多数人知晓

运行环境：Xcode 11.1 Swift5.0 最近参与的一个项目需要从Objective-C（以下简称OC）转到Swift，期间遇到了一些坑，于是有了这篇总结性的文档。如果你也有将OC项目Swift化的需求，可以作为参考。 OC转Swift有一个大前提就是你要对Swift有一定的了解，熟悉Swift语法，最好是完整看过一遍官方的 Language Guide 。 转换的过程分自动化和手动转译，鉴于自动化工具的识别率不能让人满意，大部分情况都是需要手动转换的。 自动化工具 有一个比较好的自动化工具 Swiftify ，可以将OC文件甚至OC工程整个转成Swift，号称准确率能达到90%。我试用了一些免费版中的功能，但感觉效果并不理想，因为没有使用过付费版，所以也不好评价它就是不好。 Swiftify还有一个Xcode的插件 Swiftify for Xcode ，可以实现对选中代码和单文件的转化。这个插件还挺不错，对纯系统代码转化还算精确，但部分代码还存在一些识别问题，需要手动再修改。 手动Swift化 桥接文件 如果你是在项目中首次使用Swift代码，在添加Swift文件时，Xcode会提示你添加一个 .h 的桥接文件。如果不小心点了不添加还可以手动导入，就是自己手动生成一个 .h 文件，然后在 Build Settings > Swift Compiler - General

响应式编程 Rx.NET 了解下 1. 引言 An API for asynchronous programming with observable streams. ReactiveX is a combination of the best ideas from the Observer pattern, the Iterator pattern, and functional programming . ReactiveX 使用可观察数据流进行异步编程的API。 ReactiveX结合了观察者模式、迭代器模式和函数式编程的精华 。 关于Reactive（本文统一译作响应式），有一个 The Reactive Manifesto 【响应式宣言】： 响应式系统（Reactive System）具备以下特质：即时响应性（Responsive）、回弹性（Resilient）、弹性（Elastic）以及消息驱动（Message Driven）。 很显然开发一个响应式系统，并不简单。 那本文就来讲一讲如何基于Rx.NET进行响应式编程，进而开发更加灵活、松耦合、可伸缩的响应式系统。 2. 编程范式 在开始之前呢，我们有必要了解下几种编程范式：命令式编程、声明式编程、函数式编程和响应式编程。 命令式编程 ：命令式编程的主要思想是关注计算机执行的步骤，即一步一步告诉计算机先做什么再做什么。

设计模式作为工作学习中的枕边书，却时常处于勤说不用的尴尬境地，也不是我们时常忘记只是一直没有记忆 。 今天，就设计模式的内在价值做一番探讨，并以spring为例进行讲解，只有领略了其设计的思想理念，才能在工作学习 中运用到“无形”。 Spring作为业界的经典框架，无论是在架构设计方面，还是在代码编写方面，都堪称行内典范 。 spring中常用的设计模式达到九种，我们一一举例 ： 第一种：简单工厂 又叫做静态工厂方法（StaticFactory Method）模式，但不属于23种GOF设计模式之一。 简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。 spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得bean对象 ，但是否是在传入 参数后创建还是传入参数前创建这个要根据具体情况来定。 如下配置，就是在 HelloItxxz 类中创建一个 itxxzBean 。 第二种：工厂方法（Factory Method） 通常由应用程序直接使用new创建新的对象，为了将对象的创建和使用相分离，采用工厂模式, 即应用程序将对象的创建及初始化职责交给工厂对象。 一般情况下,应用程序有自己的工厂对象来创建bean. 如果将应用程序自己的工厂对象交给Spring管理,那么Spring管理的就不是普通的bean,而是工厂Bean。

一、观察者模式的概念 观察者模式（又被称为发布-订阅（Publish/Subscribe）模式，属于行为型模式的一种，它定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使他们能够自动更新自己。 二、什么时候使用观察者模式 当一个对象被修改，或者发生某些变化时，需要自动通知依赖它的一些对象，则可以使用观察者模式。 例如：当汽车熄火时，需要更新汽车的定位、发送熄火的通知、生成本次的行程，就可以使用观察者模式，这个例子中发生变化的位置是熄火，那么发生熄火需要通知依赖它的一些对象，就是定位、通知和行程。 下面来看看，如何用Java语言实现观察者模式。 三、怎么使用观察者模式 3.1 不适用观察者模式的弊端 用上面说的业务场景为例，如果不使用观察者模式来实现，可以看下面的伪代码： public class EngineOffEvent() { public void engineOff() { Location localtion = new Localtion(); Notification notification = new Notification(); Trip trip = new Trip(); localtion.update(); notification.notify(); trip

福哥答案2020-07-24： 同步算法基于 ZAB 协议，一种快速 Paxos 算法。 快速Paxos算法 Paxos算法可能出现死循环，就是在两个Proposer总是在交替prepare。并且，Paxos算法在出现竞争的情况下，其收敛速度很慢，甚至可能出现活锁的情况，例如当有三个及三个以上的proposer在发送prepare请求后，很难有一个proposer收到半数以上的回复而不断地执行prepare。因此，为了避免竞争，加快收敛的速度，在算法中引入了一个Leader这个角色，在正常情况下同时应该最多只能有一个参与者扮演Leader角色，而其它的参与者则扮演Acceptor的角色，同时所有的人又都扮演Learner的角色。 在这种优化算法中，只有Leader可以提出议案，从而避免了竞争使得算法能够快速地收敛而趋于一致，此时的paxos算法在本质上就退变为两阶段提交协议。但在异常情况下，系统可能会出现多Leader的情况，但这并不会破坏算法对一致性的保证，此时多个Leader都可以提出自己的提案，优化的算法就退化成了原始的paxos算法。 一个Leader的工作流程主要有分为三个阶段： (1)学习阶段 向其它的参与者学习自己不知道的数据(决议);当一个参与者成为了Leader之后，它应该需要知道绝大多数的paxos实例，因此就会马上启动一个主动学习的过程

相信只要你去面试vue，都会被问到vue的双向数据绑定，你要是就说个mvvm就是视图模型模型视图，只要数据改变视图也会同时更新！那你离被pass就不远了！ 视频已录制，地址( www.bilibili.com/video/BV1qJ… ) 几种实现双向绑定的做法 目前几种主流的mvc(vm)框架都实现了单向数据绑定，而我所理解的双向数据绑定无非就是在单向绑定的基础上给可输入元素（input、textare等）添加了change(input)事件，来动态修改model和 view，并没有多高深。所以无需太过介怀是实现的单向或双向绑定。 实现数据绑定的做法有大致如下几种： 发布者-订阅者模式（backbone.js） 脏值检查（angular.js） 数据劫持（vue.js） 发布者-订阅者模式: 一般通过sub, pub的方式实现数据和视图的绑定监听，更新数据方式通常做法是 vm.set('property', value) ，这里有篇文章讲的比较详细，有兴趣可点 这里 这种方式现在毕竟太low了，我们更希望通过 vm.property = value 这种方式更新数据，同时自动更新视图，于是有了下面两种方式 脏值检查: angular.js 是通过脏值检测的方式比对数据是否有变更，来决定是否更新视图，最简单的方式就是通过 setInterval() 定时轮询检测数据变动

闲谈设计模式 Intro 设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。 了解这些前辈们总结出来的经验有助于帮助你写出来更优秀的代码，帮助你写出可扩展、可读、可维护的高质量代码。 在极客时间里推出了数据结构和设计模式的王争说了一句话，如果说“数据结构与算法之美”是教你写出高效的代码，那设计模式就是教你写出高质量的代码。 为什么要学习设计模式 提升自己代码质量，告别写被人吐槽的烂代码 提高复杂代码的设计和开发能力，设计出扩展性良好，可维护性更强，可复用性更好的代码 让读源码、学框架事半功倍，学会设计模式，在看框架源码的时候会更好的理解框架中的一些功能设计 为你的职场发展做铺垫，提升自己 code review 能力，把控团队代码质量 设计模式设计原则 设计原则是指导我们代码设计的一些经验总结，对于每一种设计原则，我们需要掌握它的设计初衷，能解决哪些编程问题，有哪些应用场景。只有这样，我们才能在项目中灵活恰当地应用这些原则。 单一职责原则 对于一个类而言，应该仅有一个引起它变化的原因 如果一个类承担的职责过多，就等于把这些职责耦合再一起，一个职责的变化可能会削弱或者抑制这个类完全其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。 开放-封闭原则 开放-封闭原则是说软件实体（类、模块、函数等等