使用场景 很多项目中都有消息分发或者事件通知机制，尤其是模块化程度高的项目。 比如：在你的系统中，很多模块都对 新建用户 感兴趣。权限模块希望给新用户设置默认权限，报表模块希望重新生成当月的报表，邮件系统希望给用户发送激活邮件…诸如此类的代码都写到新建用户的业务逻辑后面，会加大耦合度，降低可维护性，并且对于每个模块都是一个独立系统的情况，这种方式更是不可取。 对于简单的情形，观察者模式 The Observer Pattern 就足够了。如果系统中有很多地方都需要收发消息，那么它就不适用了。否则会造成类数量的膨胀，增加类的复杂性，这时候就需要一种更集中的机制来处理这些业务逻辑。 什么是发布/订阅模式(PUB-SUB) 现实中，并不是所有请求都期待答复，而不期待答复，自然就没有了状态。广播听过吧？收音机用过吧？就这个意思。 发布/订阅模式定义了一种一对多的依赖关系，让多个订阅者对象同时监听某一个主题对象。这个主题对象在自身状态变化时，会通知所有订阅者对象，使它们能够自动更新自己的状态。 特点 一个订阅者可以订阅多个发布者 消息是会到达所有订阅者处，订阅者根据 filter 丢掉自己不需要的消息(filter 是在订阅端起作用的) 每个订阅者都会接收到每条消息的一个副本...

本文介绍 10 个你可能早就知道的小技巧。 1. Create a hash from a list of values Hash['key1', 'value1', 'key2', 'value2'] # => {"key1"=>"value1", "key2"=>"value2"}...

rails 的 ActiveSupport 组件提供了很多非常有用的小功能，如果善于利用的话，可以使我们在实际项目中减少很多重复造轮子的事情。今天我们介绍的主角就是：MessageVerifier。 MessageVerifier 提供了加密和解密消息的功能，可以有效的防止信息被伪造。其源码位于 active_support/message_verifier.rb 文件，下面介绍使用方法及原理： 应用场景 跟 JWT 一样，如果你不想用别人的 gem 可以自己来写一套，用 MessageVerifier 来加密和解密 token 就行。 工作原理 加密的过程就是以某个流程将信息转化成另一个样子，解密的过程就是以相对的过程将“另一个样子”的信息还原成本来的信息。所以说这个类中一定提供了两个方法，一个是加密的，一个是解密的。...

遇到的问题 有一个项目需要存储 emoji 表情。另外极少数中文在存储的时候也遇到 utf8 编码格式的数据库在储存时报错。 Rails creating schema_migrations - Mysql2::Error: Specified key was too long 问题原因 mysql 里的 utf8...

本文总结一下 rails 中的日志相关知识点, 如日志输出, 设置日志等级, 创建新日志, 设置日志格式的方法. 输出日志 通过使用 logger 对象从 Controller, Model, View 输出日志到输出目的地: logger.debug "输出debug级别的日志" logger.fatal "输出致命错误信息" logger.error...

根据28法则，我从《97 Things Every Programmer Should Know》中摘出了其中的 20 条。剔除了其中过于明显和琐碎的内容，书中的许多技巧需要根据上下文才能更好的理解。所以有条件的话请尽量阅读原书。 1. Apply Functional Programming Principles 引用透明性是一个非常理想的性质。这意味着，不论函数在何时执行，对于同样的输入总输出同样的结果。没有副作用。 2. Ask, “What would the user...

Building applications to last - 下 Owning your stack 对于我们想要的功能，在 Ruby Toolbox 中几乎都能找到相关的 gem。听起来我们只要把这些 gems 绑在一起就能快速完成一个应用。然而，你要知道将组建加入我们的项目中所付出的代价。 当你把一个 gem 或技术引入你的技术栈的时候，你要明白 you...

Building applications to last - 上 On following fashions Ruby on Rails 的生态系统也并非一成不变的。网络上总是一天到晚的为新的设计模式或新 gem 而争吵，他们总号称能彻底改变你对 Ruby 的思考方式。 很难判断哪个框架或技术会流行，而哪个仅仅是昙花一现。 Before/after code...

Creating a system for growth - 下 Taming stylesheets 你可能觉得在一个关于 Rails 的书里面读到 CSS 感到奇怪。 然而，我们发现可怕的 stylesheets 文件夹会让你的项目快速失控。 下面这些是不是听起来很熟悉？ 你害怕修改样式，因为它会把你不可预知的某个显示效果破坏。 一个简单的...

Creating a system for growth - 中 Extracting service objects 学会权衡 ActiveModel 类之间的关联是很重要的。ActiveModel 能出色的处理面向用户的表单，它可以处理验证错误并返回相关的错误提示，这些都属于用户交互的核心功能。对于这种情况，你只需几行代码就能完成这些功能。 但是并非每一个应用或类都需要使用 ActiveRecord 或 ActiveModel。当你不需要使用 ActiveModel 的功能(比如验证，回调，脏数据跟踪等)的时候，你不应该强迫类接受...

Creating a system for growth - 上 Dealing with fat models 在前面的章节，我们把代码从 controller 移动到 model 中。我们可以看到这样带来的很多好处：controller 变得很简单，更容易测试商业逻辑。但一段时间之后，model 开始产生如下问题： 你害怕保存数据会引起意外回调，比如给客户发送个电子邮件啥的。 过多的回调和验证让你很难创建一个简单的数据来进行单元测试。...

New rules for Rails Beautiful controllers 刚接触 MVC 的开发者，最头疼的问题大概是搞不懂 controller 的作用： 很难决定把一个新功能是写在 controller 还是写在 model 中。是由 model 来完成发送邮件通知的功能还是 controller 的责任呢？支撑...

Currying in Ruby Ruby defines curry for Method and Proc, allowing procs to return partially applied procs when they get...

Debugging Rails Applications Debugging Rails With Built-in Tools Ruby compiler checks ruby -c myfile.rb 检查 Ruby 语法错误，有些语法错误会造成程序无法运行，都可以用这个命令检查出来。 不用担心，它不会真的执行你的内部命令，仅仅是检查而已。所以不用担心自己的方法被执行而造成什么破坏（比如更改对象状态）。 Gemfile.lock 这里包含了项目中用到的...

写代码时候，一些简单的 Bug 基本上打印1，2个变量就能找到原因。但是如果因为不了解 gem 而产生的 Bug 就比较难发现，这时候最好是加断点来调试。 Byebug 基础 开发环境下的 server 会自动加载 debugger byebug 是一个普通的方法，所以可以写如下代码 byebug if foo == "bar"...

基础 概念 你可以像传递对象那样传递闭包, 也可以以后调用。 当闭包创建的时候, 它记住了该环境下所有的变量的值。被调用时, 它可以访问这些变量, 甚至这些变量已处于环境的外部或其值已经改变。 Ruby 通过 proc 和 lambda 以及代码块来实现闭包。 例子 class SomeClass def initialize(value1) @value1...

组合 composition 定义的中心思想是：自行车不仅有多个零件，它还要通过接口与它们进行通信。零件是一个角色，自行车愿意与任何扮演这个角色的对象进行合作。 继承和组合的抉择 经典继承中，对象被组织成类关系，以便消息可以自动委托调用正确的行为。消息委托是免费的。 组合里，对象之间的关系没有体现在类层次结构里，对象独立存在，需要显式地进行消息委托。 一般的规则是，如果能用组合解决尽量使用组合，因为组合比继承包含了更少的内建依赖关系。 继承的优劣 代码应该满足透明、合理、可用和典范四点要求。 利，建模正确的时候。 合理性：继承结构顶部附近的方法有着广泛的影响，行为上的大变化可以通过代码的小改动来实现。 可用性：继承的代码可以用 开闭 原则来描述，对扩展保持开放，对修改保持关闭。添加新子类不需要修改已有代码。 典范性：易于扩展，提现了抽象，现有的模式很容易遵从，为编写扩展代码提供了指导。 弊，建模不正确或将继承应用到一个不适合的问题。 合理性的反面：在错误建模的层次结构的顶层附近，更改所带来的成本极高。 可用性的反面：当新子类表示的是混合类型时，很难实现行为的添加。试图将两个子类的特点结合成一个新的单一对象。 组合的优劣 利...

理解角色 有时候需要在不相关的对象之间共享行为。 找出角色 前面介绍的 Preparer 就是一个角色。那些实现了 preparer 接口的对象扮演了这个角色。而 Preparer 角色的存在表明了还存在有一个平行的 Preparable 角色。该接口包含了 Preparer 希望发送给 Preparable 的所有信息，也就是 bicycles, customers, vehicle。 尽管...

精心设计的父类易于扩展出新的子类，即使对这个应用程序不怎么了解的程序员也没问题。 理解经典的继承 继承解决了多种相关类型共享大量公共行为，但在某些层面又有所差异的问题。它允许你将共享的代码隔离起来，并在抽象类里实现公共的算法，同时又提供了一种允许子类提供特殊化的结构。 继承的核心是一种用于实现 消息自动委托 的机制。它为无法理解的消息定义了一条转发的路径。 当你需要大量特殊化某个稳定、公共的抽象结构时，继承是一种成本极低的解决方案。 弄清使用继承的地方 当某个预先存在的具体类包含你所需要的大部分行为时，多数时候我们会直接往这个类里添加代码来解决新问题。这种模式表面上能带来好处，但实际上却是有害的。 下面是一段错误的示例： class Bicycle attr_reader :style, :size, :tape_color, :front_shock, :rear_shock def initialize(args)...

面向对象设计的目的在于要减少变化所带来的成本。既然我们知道了消息是应用程序的设计中心，而且致力于构建出严格定义的公共接口，那么可以结合一下这两种技术，进一步降低成本，也就是鸭子类型。 鸭子类型指的是不会绑定到任何特定类的公共接口。这种跨类接口能为应用程序带来巨大的灵活性，所采用的方式是利用更加宽容的 消息依赖 取代昂贵的 类依赖。 理解鸭子类型 什么是类型 类型就是描述变量内容的分类。 过程语言提供了少量固定的类型，通常用来描述各种类型的数据。而变量类型，让应用程序假设：数字可以用于数学表达式、字符串可以连接、数组可以索引。 Ruby 中的类型 在 Ruby 中，对某个对象的行为期望是以信赖其公共接口的形式表现出来。如果知道一个对象的类型，就知道这个对象可以响应哪些消息。对象的使用者不需要关心它的类。类只是对象获得公共接口的一种方式。 我们要关心的是对象具体做什么，而不是这个对象是什么。 鸭子类型概述 class Trip attr_reader :bicycles,...

面向对象的应用程序是由对象之间传递的消息所定义的。这种消息传递发生在 “公共” 接口上。定义良好的公共接口由稳定的方法构成，这些方法暴露的内容就是它们的基础类锁具备的责任。 设计必须关心对象之间传递的消息。它要解决对象所知道的内容(职责)，以及对象都知道谁(依赖关系)，还要解决彼此间如何进行对话的问题。 本章学习使用时序图来设计、定义公共接口，以及发现对象。 理解接口 类实现了许多方法，有些方法旨在被其他对象使用，这些方法便组成了这个类的公共接口。 你可以想象一下，厨房的公共接口就是菜单。顾客只需要点菜就好，别进来指挥怎么做菜。 定义接口 通用方法将主要职责暴露给细小实用的方法，而细小的方法则只在内部使用。这里通用方法就是指公共接口，而细小的方法是指私有方法。 公共接口 暴露了其主要职责 期望被其他对象调用 不会因一时兴起而改变 对其他依赖它的对象来说很安全 在测试里被详尽记录 私有接口 要处理实现细节 不希望被发送到其他对象 可以因任何不明原因而变化...

我们的目标是：管理好依赖关系，以便让每一个类都拥有尽可能少的依赖关系。 因为精心设计的对象都具有单一职责，因此它们在本质上要求通过合作来完成复杂的任务。这强大而危险。为实现合作，一个对象必须知道其它对象的某些情况。这便形成了一种依赖关系。 class Gear attr_reader :chainring, :cog, :rim, :tire def initialize(chainring, cog, rim, tire) @chainring = chainring @cog = cog...

决定类的内容 面向对象系统的基础和核心是消息(message)，但最明显的组织结构是类(class)。 将方法组织成类 你所创建的类会永久的影响你对这个应用程序的思考。 尽管将方法正确分组成类很重要，但在项目的早期由于所了解的需求太少，所以不可能将它处理得很正确。 设计是保留可变性的艺术，而非达到完美性的行为。 组织代码以便于更改 易于更改 更改不会产生意想不到的副作用 需求的轻微变化对代码的更改要求也相应较小 现有的代码易于重用 最简单的更改方式是添加其自身也易于更改的代码 编写出的代码应该具有以下几个特点(TRUE 原则) 透明性 Transparent: 在当前类和依赖于当前类的其它类中，更改所产生的后果显而易见 合理性 Reasonable: 更改的成本和效益成正比...

前言 随着代码的增长和对需求的变化，那些当前系统里还不存在的业务逻辑将会添加进去。在所有的情况中，代码的可维护性在整个项目的生命周期中始终比优化其现有状态更加重要。 常见的设计原则：SOLID原则，DRY原则，TRUE原则。 常见的设计模式：工厂模式，组合模式，模板方法。 TRUE原则：具有透明性、合理性、可用性和典范性的代码，不仅能满足今天的需求，也因便于修改而能满足未来的需求。 第一章 面向对象设计 OOD 的失败并非是编码技术的失败，实际上是视角的失败。 设计赞歌 设计解决的问题 客户并不知道自己想要的是什么，所以需求总是会不停的更改和新增。即便该应用程序取得了成功，但是大家仍然期望得到更多新功能。正是这种变化的需求让设计变得如此重要。 为何难以更改 面向对象设计与依赖关系管理相关。它是一套对依赖关系管理进行编排，以便各个对象能够容忍更改的编码技术。 在缺乏设计的情况下，对象彼此之间了解过多，任何一个对象的修改都会强制要求其合作者也随之发生变化。 实用的设计定义 设计的目的是允许你以后可以进行设计，而设计的首要目标是降低变化所带来的成本。 设计工具 设计原则 SOLID原则...

文本 名称 作用 abbrev 计算一组字符串的可能缩写 base64 处理Base64编码的模块 csv CSV文件读取和写入 digest 消息摘要库 erb 嵌入Ruby json JSON文件读取和写入 psych YAML文件的解析 yaml 序列化YAML格式的文件 rexml...