reusable

作者 | Daniel B. Markham 译者 | 王者 策划 | 万佳 为什么实现组件可重用性如此之难？ 几周前，Uwe Friedrichsen 在他一篇博文中提出一个这样的问题： ……可重用性是软件的制胜法宝：每当一个新的架构范式出现，“可重用性”就成了是否采用该范式的一个核心考虑因素。业务通常会这样认为：“转向新范式在一开始需要多付出一些成本，但因为可重用，所以很快就会从中获得回报”……但简单地说，任何基于可重用的架构范式从来都不会像承诺的那样，而且承诺总是无法兑现…… 他例举了 CORBA、基于组件的架构、EJB、SOA 等例子，然后就问微服务是否会带来不一样的结果。 为什么可重用性的承诺总是无法兑现？为什么我们无法写出真正可重用的代码？ 这些都是很好的例子，Friedrichsen 很好地解释了为什么实现可重用性是如此困难。然而，我相信，他忽略了关键的一点：经典的面向对象编程（OO）和纯函数式编程（FP）在可重用性方面会有截然不同的结果，因为它们基于不同的假设。 我们来做个实验，分别用 F# 和 C# 以 FP 和 OO 的方式来实现“FizzBuzz”游戏。 首先是 F#： let (|DivisibleBy|_|) by n = if n%by=0 then Some DivisibleBy else None let findMatch = function

来源： oschina 链接： https://my.oschina.net/u/4313085/blog/4696384

感谢支持ayqy个人订阅号，每周义务推送1篇（ only unique one ）原创精品博文，话题包括但不限于前端、Node、Android、数学（WebGL）、语文（课外书读后感）、英语（文档翻译） 如果觉得弱水三千，一瓢太少，可以去 http://blog.ayqy.net 看个痛快 一.出发点 在 React 现有的组件模型下，存在很多难以解决的问题： 难以跨组件复用状态逻辑 组件复杂度高难以理解 Class 的诸多弊病 …… 而 Hooks， 肩负着破局使命 组件间逻辑复用 组件间逻辑复用一直是个问题，Render Props、Higher-Order Components等常用 套路 模式都是为了分离横切关注点（Cross-cutting concern），复用诸如： 日志 缓存/同步/持久化 数据校验 错误捕获/异常处理 的逻辑，目的是 将横切关注点与核心业务逻辑分离开 ，以便专注于业务逻辑 P.S.关于切面、关注点等 AOP 概念的更多信息，见AOP(Aspect-Oriented Programming) 然而，HOC 与 Render Props 虽然能以组件形式分离横切关注点，但也带来了一些新问题： 扩展性限制 Ref 传递问题 Wrapper Hell 之所以会出现这些问题，根本原因在于： 细粒度代码复用不应该与组件复用捆绑在一起

前面一篇文章《 最近架构随想 》，我提到架构设计的一些构想，其实也是对之前项目经验的一些归纳及总结。今天我们就以权限系统作为切入点，谈一谈怎么设计权限系统以及怎么做到系统具有以下特性： Organized：如果系统组织比较好，可以起到事半功倍的效果。 Encapsulated：对功能，结构，数据进行有效的封装，会使系统维护变得更加容易。 Reusable：对常用功能以及组件进行有效的封装，可以使系统变得结构清晰且方便维护。 Extensible：在设计系统的时候，如果很好的遵守OO的设计理念（OO的五大原则SOLID），即使系统做得很大，也会像火箭一样直冲云霄！ Replaceable：在很多时候我们需要考虑到系统，组件或者功能的可替换性，因为需求是会变的。 Testable：做到系统的可测性，会大大帮助开发以及维护，对团队开发以及分工协作起着非常重要的作用。 Loose Coupling：隔离耦合是架构设计必须要考虑的一个因素，如果系统不能做到高内聚、低耦合，那么在维护，升级，新功能开发方面就会是一场噩梦！ High Performance：高性能是系统设计必须重视的要点，用户不可能忍受简单页面加载超过十秒，也不可能接受页面操作频繁卡死的情形，所以在架构设计的时候必须从数据库，逻辑，服务以及UI进行合理的优化。 Scalability：如果能做到前面的几点

一个软件系统中往往包含了很多的类，这些类之间会存在互相的调用，随着系统的升级、功能的扩展，这些相互调用关系会变得非常复杂，，大量的相互连接使得这样一个类型系统不太可能在没有其他类支持的情况下独立完成工作，久而久之这些类将变得像一个不可分割的整体，内部有着错综复杂的关联。这会导致后期维护特别困难，对系统或模块的任何较大的变动都可能造成无法预知的问题。 中介者模式 中介者模式可以解决这种问题。它通过提供一个中介类，来处理不同类之间的通信，这样可以降低多个类之间的通信复杂度，使代码更易于维护。中介者模式属于行为型模式。通过应用Mediator模式，可以将类与类之间的多对多的关系转化成一对多的关系，从而降低了类之间的耦合。 GOF对中介者模式描述为： Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.. — Design Patterns : Elements of Reusable Object-Oriented

原型模式 原型模式的适用场景 浅拷贝 深拷贝 用Initialize方法修改初始化状态 原型模式与之前学习的各种工厂方法、单例模式、建造者模式最大、最直观的区别在于，它是从一个既有的对象“克隆”出新的对象，而不是从无到有创建一个全新的对象。与对文件的拷贝类似，原型模式是基于现有的对象拷贝新的对象。 原型模式 GOF对原型模式的描述为： Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.. — Design Patterns : Elements of Reusable Object-Oriented Software 原型模式的构造对象的的过程是，选择一个现成对象（原型对象），通过调用它的“克隆”方法来获得一个和它一样的对象。 其UML类图为： 原型模式的适用场景 原型模式适用与如下场景： Factory、Builder、Singleton返回的都是“初始状态”的对象，但有的时候需要的对象反而是处于某种状态的对象； 如果一个对象的初始化需要很多其他对象的数据准备或其他资源的繁琐计算，则可以使用原型模式直接克隆； 当需要一个对象的大量公共信息，少量字段进行个性化设置的时候

抽象工厂，决定产品系列的产品的组合，特点是创建同一款式的产品系列。缺点是增加产品组件，需要修改抽象工厂接口，影响抽象工厂子类。 builder，决定产品的各个部分的build的过程。替换相应的builder子类，就可以修改产品相应的各个part部件的实现；替换相应的Director子类，就可以修改builder组件的调用顺序（即控制创建过程）。 工厂方法，产品子类和creator子类一 一对应。不直接调用FactoryMethod操作，定义了何时调用FactoryMethod。扩展相关子类可以修改此调用时间 Prototype，产品自身就是自己的creator Singleton，产生全局的单一实例 1）以上是创建型：创建型设计模式核心是通过替换直接调用new创建具体对象这种方式，从而去client代码和产品对象之间的耦合。client都是通过接口引用工厂，通过接口引用产品，所以替换更方便。 adapter，描述了client如何做到通过target接口，来使用Adaptee的操作函数。 bridge，“抽象接口定义”和“具体实现部分”分离。分离后，可以各自发展。 composite，从共同接口派生，使对单个对象和组合对象的使用具有一致性，并且支持递归组合。 Decorator，共同的父类，接口相同，可以透明的、递归的增加额外的职责。与composite区别是只有一个组件

一、定义 　　设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是 为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。 二、产生背景 　　肯特·贝克和沃德·坎宁安在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也会用于指代前面提到的那本书。 三、学习的意义 　　设计模式的本质是面向

本文将介绍HBase的客户端连接实现，并说明如何正确管理HBase的连接。 最近在搭建一个HBase的可视化管理平台，搭建完成后发现不管什么查询都很慢，甚至于使用api去listTable都要好几秒。 经过一番排查发现，是每次请求的时候，都去临时创建了一个connection，而创建connection非常耗时导致整体的rt上升。 因此，就深入了解了下如何正确管理HBase的connection，同时，也在优化过程中有些小细节的总结。 本文基于hbase 2.0.0版本的源码，github上3.0版本的源码已经有很大差异了，但是思想还是差不多的 1.HBase-client和HBase是如何连接的？ 这个问题实际上在我之前的文章 深入HBase读写 中介绍过。 当HBase-client第一次请求读写的时候，需要三步走： 1）HBase-client从zk中获取保存meta table的位置信息，知道meta table保存在了哪个region server，然后缓存这个位置信息； 2）HBase-client会查询这个保存meta table的特定的region server，查询meta table信息，在table中获取自己想要访问的row key所在的region在哪个region server上。 3）客户端直接访问目标region server，获取对应的row 所以

迭代器模式 基于IEnumerable的实现 使用场景 迭代器模式的优缺点 迭代器模式 迭代器模式用于顺序访问集合对象的元素，而不需要知道集合对象的底层表示。Java和.Net等语言已经将迭代器作为其内部语法元素，比如在C#中，集合对象只需要实现IEnumberable接口，然后就可以用foreach来遍历了。 迭代器模式提示我们要从使用者的角度考虑如何设计接口，如何对外提供访问内部对象的方式。即便我们组织的对象系统内部结构很复杂，但对于客户程序而言最简单的方式莫过于通过for /foreach循环依次遍历，至于遍历过程中的次序、分类筛选等则由目标类型自己封装。 GOF对迭代器模式描述为： Provide a way to access the elements of an aggregate objectsequentially without exposing its underlying representation. — Design Patterns : Elements of Reusable Object-Oriented Software UML类图： 代码实现 //迭代器接口 public interface IIterator<T> { T Next(); bool HasNext(); } //具体迭代器 public class