设计模式之编程思维

设计模式之编程思维

最近学习设计模式，有点感悟，写一下课堂笔记，加深自己的理解，整理出来；同时分享给大家，传递一下好的编程思维。

学习思维

在学习设计模式时，我们通常会觉得：

1. 经典设计模式太抽象，很难学下去。其实经典之所以经典，是因为包含的知识密度太高，需要花费时间去理解，去解读；我们需要了解设计模式能解决哪些范围的问题后，才能正确的使用。

2. 设计模式太单一，业务复杂难落地。在理论学习中，几乎所有的开发人员都认为它很重要；在工作实践中，绝大多数开发人员在项目中又找不到合适的应用场景。其实这关键在于搞清楚设计模式解决问题的范围所在。设计模式并不是一种全场景解决方案，它需要考虑适用范围。

3. 很多人就认为编程时应该处处使用模式，并且用得模式越多，设计就越好。事实上，好的设计从来不是看用的模式有多少，而是看如何合理利用模式的设计思想，以及如何利用模式解决真实的问题。

如何学习它呢，我们应该具有正确的学习思维：

首先，要摆正心态。 设计模式不是万能灵药，不是银弹，设计模式能解决的问题其实是有限的，你应该始终保持一个平常的心态，正确分析设计模式可以解决和不能解决的问题。

**其次，搞清楚设计模式的背景知识。**学习一门知识时，如果总是忽略关联的背景知识，久而久之会养成零碎知识积累的习惯。

**再次，努力具备高手独立思考的习惯。**我们这个时代，不缺资料和方法，缺的是能解决复杂难题的高手。高手之所以成为高手，是因为高手不拘泥于某一知识的高低贵贱，而是保持明智的判断，始终朝着坚定的目标前行。你的身边一定有这样的隐藏高手，我们应该向他学习。

最后，从现在开始，坚持。 学习技术知识，不比看文学小说，需要面对更为枯燥的业务场景，有时还需要反复做一些你可能不太喜欢的重复工作。但只有坚持才能成长，才能锤炼出属于你自己的真实能力。记住，一定坚持住。

组合思维

作为开发者，你一定对Unix系统比较熟悉，他背后有着一个伟大的Unix哲学。Unix 哲学，主张组合设计，而不是单体设计；主张使用集体智慧，而不是某个人的特殊智慧。

• 启示一：保持简单性

Unix哲学中的“简单原则”，是被应用最多的原则之一。我们现在更习惯称之为模块化。大致的宗旨是：一个程序只做一件事，并做得很好。

• 启示二：组合思维

Unix中的组合例子：所有的命令都可以使用管道来交互；可以替换任意程序，每个程序就像零件一样，可以任意插拔；自定义环境变量等；这充分说明了 Unix 哲学的组合思维：把软件设计成独立组件并能随意地组合，才能真正应对更多变化的需求。

• 启示三：数据思维

如今，在互联网应用中，绝大多数应用程序都是数据密集型的，而非计算密集型。在数据密集型应用中，处理数据是主要挑战，而使用 CPU 计算不是瓶颈，更大的问题来自数据量、数据复杂性以及数据的变更速度。Unix 哲学在出现之初便提出了“数据驱动编程”这样一个重要的编程理念。也就是说，在 Unix 的理念中，编程中重要的是数据结构，而不是算法。

分层思维

• 代码分层架构是什么：

代码分层架构就是将软件“元素”（代码）按照“层”（代码关系）的方式组织起来的一种结构。

分层架构核心的原则是：当请求或数据从外部传递过来后，必须是从上一层传递给下一层。一个来自 View 层的数据，必须先通过 Controller 层、Model 层后，才能最终到达数据库层。

那么你可能会问：“为什么不让 View 层的请求直接到达数据库呢？”这是因为会造成新的代码耦合，增加代码的复杂度。比如说，View 层直接调用 Model 层的组件，当 Model 层上的组件有变化时（比如， SQL 或逻辑修改），既会影响 Controller 层组件的使用，也会影响 View 层组件的使用。

所以，分层的本质就是为了让相似变化在各自的层内变化，而不造成层与层之间的相互影响。

• 代码分层架构解决什么问题：

1. 通过分层拆解问题；一个功能需求问题通常都是笼统的复杂问题，我们一般都会将这个笼统的复杂问题拆分为多个层次的子问题来解决。从功能性需求角度来看，代码分层本身就是一种拆解复杂问题的好方法。

2. 通过分层来提升代码的扩展性；分层架构可以将复杂的逻辑切分为多个层，这样大问题就变成了多个小问题，而我们可以很方便地解决每个小问题。每个小问题更容易被抽象为一个组件，当组件功能需要扩充或替换时，修改代码的影响也被有效地控制在有限的范围内，这样组件自身的复用性也就提高了。

工程思维

• 什么是软件工程？

先说一下软件开发：

软件开发，在狭义上的定义是指软件编程，也就是我们常说的编写和维护代码的过程。

但其实，从广义上来讲，软件开发是指根据用户要求构建出软件系统或者系统中软件部分的一个产品的开发过程。换句话说，软件开发是一系列最终构建出软件产品的活动。现在，我们常用“软件开发过程”这个词来表述。这个过程包含了 6 个关键活动阶段，用公式表达就是：软件开发过程 = 定义与分析 + 设计 + 实现 + 测试 + 交付 + 维护。不管是小到一个程序的某个模块的开发，还是大到行业级的软件项目，只要是软件开发，都离不开这个本质过程。

软件工程（Software Engineering），是软件开发里对工程方法的系统应用。 这里的软件开发其实就是指软件开发过程，也就是说，软件工程研究的对象就是软件开发过程，只不过是借鉴了工程方法来对这个过程进行优化。

实际上，软件工程对过程的改进思维，能够应用于很多方面，包括工作中的代码编写、架构设计、需求分析、制订计划、项目管理等。无论你是一个普通工程师还是项目管理者，都应该学点软件工程方法。

我想强调的是我们应该利用工程的思维去从事软件开发，而不仅仅只是关注软件编码，忽视了软件开发过程中的其他流程。

对象思维

• 面向对象编程有哪些优势？

1. 模块化更适合团队敏捷开发

2. 对象结构更能提升代码重用性、可读性；

   面向对象有三大特性：封装、多态和继承。

3. 组合和聚合思想让代码演进更重视组件化

面向对象编程有三大优势：模块化、对象结构和组合/聚合思想。你会发现，它们的核心理念都是在提升代码的可扩展性、可重用性和可维护性。80% 的时间里代码都是在被阅读的，如果一段代码很难阅读，那么维护人员修复起来就会非常耗时耗力，而且难读的代码扩展性也非常差，任何的新增功能都有可能引入更多未知的问题。

迭代思维

什么是迭代？简单来说，每一次对过程的重复就被称为一次“迭代”，而每一次迭代得到的结果会被用来作为下一次迭代的初始值。迭代有如下三个关键特征。

1. 每一个迭代都应该有输入、处理和输出
2. 记录版本
3. 不断更新

编程本身就是一个重复的过程，你可能经常在用迭代，不过可能会在无意间忽略了迭代的关键点——记录版本。

当你在编程时，会面临一个问题：每一次的代码修改都会或多或少覆盖原有的代码，久而久之，代码可能是最新的，功能看上去也是最全的，但你想要回顾时，却发现历史版本太难寻找，比如，一直使用 1.0-SNAPSHOT 的版本号。

如果没有历史版本，你会很快忘记过去开发过哪些功能、没开发过哪些功能，虽然功能不断在迭代前进，但一年后你几乎就会忘记你曾经做过什么。

正确的做法是：记录版本并且记录每一次关键修改信息。

如果你时常把编程干成这样：编程 = 写代码 + 写代码 + 写代码……那么你一定要及时停下来想想，编程到底意味着什么。

编程 ≠ 写代码。 不要把你的有效时间，浪费在只写代码上，这样你的编程能力甚至个人成长都会变慢。

编程不是一个体力活，编程应该是一个综合的脑力活：编程 = 写代码 + 讨论 + 学习 + 反思。