主要记录了工作之余胡乱学习的知识，大部分是入门级别的内容。 主要是为了自己未来有用到时能快速上手，相当于是个备忘录。 当然，也很开心其他人可以从中找到对自己有用的信息。^_^

本章涵盖了一些与C++API设计相关的设计模式和惯用法。

本章内容就是在回答一个问题：好的API应该具备哪些特征？下面就是从几个方面来解释应具备的特征

《C++API设计》读书笔记（1）：API简介

原文链接：https://flamendless.github.io/ecs-vs-oop/

“隐喻”的作用是什么？——通过把你不太理解的东西和你一些较为理解、且十分类似的东西作比较，你可以对这些不太理解的东西产生更深刻的理解。（这种隐喻的方法也叫“建模(modeling)”）隐喻是对概念进行内在化(internalizing)和抽象(abstract)的一种途径，它让人们在更高的层面上思考问题，从而避免低层次的错误。——Fernando J. Corbató不过有时候，当隐喻的概念被过度引申时，模型也会误导人们。人们对声波理论和光波理论进行对比研究的成功丰富，于是想寻找一种能在真空中传

《代码大全第2版》读书笔记（1）：欢迎进入软件构建的世界

第8章：注重实效的项目随着项目开动，我们需要从个体的哲学与编码问题，转向为项目级别的问题。本章将讨论影响项目成败的几个关键区域。41《注重实效的团队》本书在先前讨论了帮助程序员个体更好的方法，这些方法对团队也有效。下面将针对团队，来重述前面部分章节。不要留破窗户。团队不应该容忍那些小小的、无人修正的不完美。煮青蛙。团队更容易被煮熟，因为每个人都觉得别人会在监视环境的变化。交流。不仅团队内部需要交流，团队也需要和外部交流。不要重复你自己。消除团队成员之间的重复。正交性。我们喜欢围绕功能、

第7章：在项目开始之前本章讨论了在项目开始之前要面临的问题。36《需求之坑》

第5章：当你编码时有人认为，项目一旦进入编码阶段，便是机械劳动，这是错误的。编码不是机械劳动，程序员每分钟都需要进行思考做出决策。本章讲的是实际编码时要注意的细节：主动思考代码为何能工作，而不是靠巧合编程。评估算法速率。不断地在代码设计中看到改进的余地，进行重构。记住你未来要对代码进行测试，所以你需要编写易于测试的代码。小心那些帮你写大量代码的工具，比如邪恶的向导。31《靠巧合编程》我们应该避免靠巧合编程——依靠运气和偶然的成功。而是应该深思熟虑地编程。巧合包括：实现的偶然。

第5章：弯曲，或折断我们需要让自己的代码在面对不确定的世界时保持灵活性和可适应性。以下是方法：解耦。让分离的概念保持分离，降低模块间的耦合程度。将一些细节移出代码。减少时间上的耦合。将模型与视图分离。一种解耦的技术：提供一个“聚会地点”，各模块可以在那里匿名和异步地交换数据。26《解耦与得墨忒耳法则》在《正交性》和《按合约设计》中我们提出，应该编写“羞怯”的代码，其工作方式有两种：不向别人暴露你自己不与太多人打交道让模块相互了解有什么问题？原则上没有。但是过多的直接依赖关

第4章：注重实效的偏执每个人都知道只有自己是好司机，其他人都不会好好开车。——因此，你需要在麻烦发生之前小心谨慎、预判意外之事、从不让自己陷入无法解救自己的境地。而一个“注重实效的”程序员会更进一步——他们连自己也不信任。因为他们知道没人能编写完美的代码，自己也不例外。因此，需要对错误进行防卫性编码。本章的内容即是各种防卫策略：21《按合约设计》合约既规定你的权利与责任，也规定对方的权利与责任。此外，还有关于一方未遵守的后果的约定。我们也可以采用同样的理念来帮助软件模块进行交互。DBC（D

第3章：基本工具工具放大你的才干。本章讨论的工具包括：使用纯文本存储数据使用shell进行自动化14《纯文本的威力》纯文本，又称“可读文本”，与之相对的是二进制格式。“纯文本”相对而言的两个主要缺点：存储空间更大解析代价更高“纯文本”的威力：保证不过时易于版本管理（方便查看历史的修改）易于操控15《shell游戏》shell，在Windows上相当于”命令行“，与之相对的是”图形界面(GUI)“。GUI使用简单：好处是 WYSIWYG（What you see

第2章：注重实效的途径这一章讲的是：通用于软件开发各个层面的道理。7《重复的危害》系统中的每一项知识都必须具有单一、无歧义、权威的表示简称为DRY（Don’t Repeat Yourself）否则，当一个知识需要变化时，就需要改动多处，假如没有改全则会造成矛盾。这算是最重要的道理之一。大多数重复都可归为如下范畴：强加的重复——开发者觉得他们别无选择，因为环境似乎要求重复。例如：代码中表示了一遍知识，随后文档又描述了一遍相同的内容。多个平台需要各自的编程语言，开发环境。编程语言自

第1章：注重实效的哲学本章节讲的是：作为一个注重实效的程序员，你应该有哪些态度？接下来的小节便是这些态度：1 《我的源码让猫给吃了》——对自己的代码负责我们对自己的能力自豪，但也对自己的错误诚实。在承担事物之前应进行评估，对于做不到或者风险太大的事情要说“不”。如果同意承担了一件事物，就对它负责。这意味着：如果客户不能接受风险，则提前要有应急计划。如果出了错，要说明做什么可以挽回。如果需要更多的时间进行 “重构”、“制作原型”、“引入更好的测试”、“写自动化工具”等，则解释其价值。

第7章：为什么巴比伦塔会失败为什么？因为缺少交流。文档（手册）很重要。但有一种看法认为：编程人员只了解自己负责的部分效率更高。确实，但这要求精确，完整地定义所有地接口。【产品负责人】&【技术主管】...

读后感说是“读后感”，其实并不是看得很仔细，尤其是各种代码例子，我基本上是跳过的。个人觉得，重构这件事上，关键是要能嗅出坏代码，知道什么是好代码，这样目标明确后，重构的手段其实是水到渠成的，唯一要注意的就是书中强调的：要以小步为单位稳打稳扎进行。我所理解的“好”代码核心目标那么如何才是“好”代码？书中的答案是：“人们是否能轻而易举地修改”，而我觉得抽象层级更高的描述是：易于未来的工作。“未来的工作”包括了“修改”，也包括其他方面的如“调用”，所以我觉得是个更加准确的描述。易于未来的工作具体的

重构“重构”指的是一种对代码结构的改善。这种改善：不会改变代码的外在行为。不会让代码效率更高（准确来说，效率可能会变低）会让代码设计变得更 好 。而代码怎么算是 好 ，以及怎样才能变 好，就是本书所讨论的内容。本书目录：第1章，用一个实例来说明什么是“重构”。第2章，讨论“重构”的一些概念。例如：什么是重构、重构与新功能、重构与架构、为何要重构、何时重构、重构面临的挑战、重构与性能 等等。第3章，代码的“坏”味道，讨论一个 坏 代码的表现。第4章，强调构建“自测试体系”的重要性。第

这篇博客记录了书中《第4章：结构型模式》里的要点。介绍结构型模式涉及如何组合类和对象以获得更大的结构。结构型类模式采用继承机制来组合接口或实现。一个简单的例子就是采用多重继承方法将两个以上的类组合成一个类。结构型对象模式不是对接口和实现进行组合，而是描述了如何对一些对象进行组合。因为可以在运行时改变对象组合关系，所以相比前者有更大的灵活性。Adapter（适配器）意图Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。想要解决的问题例如：自己在写一个图形编辑器时

模式之间并不是对等、互斥的。他们之间是相互配合的，更像是一种“设计思路”

这篇笔记讨论了【第二章 实例研究：设计一个文档编辑器】中的内容。概括讲，这一章通篇在讨论一个名叫Lexi的文档编辑器该如何设计，这其中牵扯到了一些问题。对于每一个问题，程序设计上都会有多个途径可以解决，但是其中有优劣。一个“好”的设计，被期望有一些特点，这些特点会在各方面表现得更优秀。而最终讨论出的解决方案，背后其实是反映了一种设计模式。下面，就是这些问题：文档物理结构文档物理结构的问题是...

目录分析概括来讲，这本书先讲了“设计模式”的基本概念，研究了一个设计案例，然后重点讲解了23个设计模式。目录如下：引言实例研究：设计一个文档编辑器创建型模式（5个）结构型模式（7个）行为型模式（11个）结论待定杂项图示的规则文档总结下设计模式怎样解决设计问题待定自己的思考问题的解决是有通用的解决方案的虽然许多对象来源于现实世界的分析模型，但是也有很多对象现实中并不存在。待定原话...