《设计模式沉思录》的原文摘录

  • 乱中求序是自然科学的主旋律。 (查看原文)
    晨星 2018-11-05 14:27:59
    —— 引自章节:序
  • 局促不安只能使人无所作为。只要关注最基本的东西,其他东西会随之而来的。 (查看原文)
    晨星 2018-11-05 14:35:53
    —— 引自章节:前言
  • GoF: Erich Gamma Richard Helm Ralph Johnson John Vlissides (查看原文)
    晨星 2018-11-05 14:41:34
    —— 引自章节:前言
  • 要防止夸大其词的宣扬引发抵触情绪,最好的方法就是——少说多做。 (查看原文)
    晨星 2018-11-06 18:34:19
    —— 引自第6页
  • Adapter让我们改变一个类的接口。 Bridge让我们改变一个类的实现。 Composite让我们改变对象的结构和组成。 Decorator让我们改变职责而无需派生子类。 Facade让我们改变一个子系统的接口。 Flyweight让我们改变对象的存储开销。 Proxy让我们改变如何访问一个对象以及改变对象的位置。 (查看原文)
    晨星 2019-01-13 22:52:30
    —— 引自第22页
  • 当我们需要对一个对象进行引用,但这个引用需要具备更多的功能或要比一个简单的指针更加复杂时,Proxy模式就适用。 (查看原文)
    晨星 2019-01-13 23:41:43
    —— 引自第23页
  • 我们迫切地希望能避免修改已有的代码(可以理解为“向已有的代码中添加bug”)。 (查看原文)
    晨星 2019-01-13 23:44:03
    —— 引自第27页
  • 使用重载的时候,子类必须覆盖所有的函数,否则C++中对虚拟重载函数的选择性覆盖会隐藏基类中的一个或多个操作。 (查看原文)
    晨星 2019-01-13 23:46:08
    —— 引自第32页
  • 与框架相比,Template Method模式在一个较小的规模上——操作级别而不是对象级别——提供了这些好处。 (查看原文)
    晨星 2019-01-15 00:27:09
    —— 引自第40页
  • Abstract Factory关注的是创建一系列的对象而无需指定具体的类。 Builder关心的是创建复杂的对象。使用相同的步骤来构造对象,而这些对象具有不同的表现形式。 Factory Method的意图与Abstract Factory相似,除了没有强调对系列的支持。 Prototype把待创建对象实例的类型放到参数中。用一个(运行时可替换的)实例作为原型,并调用它的copy操作来创建新的实例。 Singleton确保每个类只有一个实例,并提供一个全局访问点来访问该实例。 (查看原文)
    晨星 2019-01-15 00:30:39
    —— 引自第43页
  • Composite模式描述了叶节点和复合节点之间的递归关系。它给所有的节点以完全相同的接口,这样我们不仅能以统一的方式来处理它们,而且能以层级的形式来组织他们。 (查看原文)
    晨星 2019-01-16 00:56:23
    —— 引自第48页
  • Mediator模式将对象之间的交互升格为完整的对象状态。通过不让对象显式地相互引用,它促进了松耦合。 (查看原文)
    晨星 2019-01-16 00:58:33
    —— 引自第49页
  • 软件行业因为它的“免责声明”而臭名昭著。 (查看原文)
    晨星 2019-01-16 01:00:41
    —— 引自第65页
  • Momento模式的意图是记录对象的状态并将状态保存在外界,以便日后将对象恢复到原来的状态。 (查看原文)
    晨星 2019-01-18 01:03:37
    —— 引自第95页
  • (C++)友元关系是不能继承的。 (查看原文)
    晨星 2019-01-18 01:04:59
    —— 引自第97页
  • 如果一个程序的控制流由外部因素(称为事件)所控制,那么该程序是事件驱动的(event-driven)。 (查看原文)
    晨星 2019-01-18 10:27:19
    —— 引自第112页
  • 我们三个人认为值得将Multicast归结为一个模式,而Ralph却认为它只是Observer模式的一个变体。 (查看原文)
    晨星 2019-01-19 01:10:02
    —— 引自第118页
  • CPTP: Curiously Recurring Template Pattern. (查看原文)
    晨星 2019-01-19 01:14:29
    —— 引自第129页
  • 在软件开发周期变得越来越短的今天,任何分散注意力的行为完全是不可想象的。 但反思至关重要。再没有什么能够比不假思索地实现功能更容易将开发人员导向墨守成规、缺乏创新的套路了。 (查看原文)
    晨星 2019-01-19 01:16:46
    —— 引自第134页
  • GoF在编写设计模式的过程中,有一条不能违背的规则:在将一个问题及其解决方案编写成一个模式之前,必须找到两个现成的例子。 我们想要确保自己写出来的模式在现实中是站得住脚的,我们不希望得出一些解决方案来解决没有人需要解决的问题。 (查看原文)
    晨星 2019-01-19 01:20:44
    —— 引自第135页
<前页 1 2 后页>