趣学设计模式

说到面向对象编程，有一个原则几乎每个程序员都知道，那就是 SOLID 原则。关于它的资料介绍也非常丰富，实践例子也很多。但实际上你很可能把 SOLID 原则都用错了，并且还无意识地一直在滥用它。 之所

在面向对象编程中，你是不是经常听到“要实现代码间的职责分离”，但是具体什么样的代码才算得上是清晰的职责分离，似乎却又总是模糊不清。比如： 代码模块越多职责越清晰？ 按照需求来分配职责就是职责分离？ 模

维护代码是程序员非常重要的日常工作之一，那么你是否曾遇见过以下问题？ 接手维护项目，却发现文档缺失、代码无注释，加上维护人离职，基本只能靠猜来梳理代码逻辑。 代码风格过于抽象（命名过短、魔鬼数字、重名

在实际的软件开发中，我们经常会写下面这样的代码： 代码看上去没有太大的问题，但实际上其中任意一个方法发生变化时，这段代码都需要修改。因为调用是依赖的每一个细节，不仅增加了耦合，也使代码结构僵化。 迪米

大家发现没，设计原则通常都有一个很普遍的特点：语言很简练，听上去很有道理，但是拿来指导实践根本无从下手。比如说，在学习简单原则（也就是我们平时说的 KISS 原则） 时，你可能遇到过下列问题： 为什么

在软件开发中，我们都学习过一些经典的设计原则，其中包括面向对象原则（SOLID）、简单原则（KISS）、单一原则（DRY）、最少原则（LoD）、分离原则（SoC）等。 分开来看这些原则时，会觉得它们都

在编程的路上，大家是不是曾有过这样的经历：虽然学会一门编程语言后会写代码了，但是有时写出的代码可能并没有想象的那么好。比如： 代码只要没有经过测试，发布上线后总是会频繁发生故障； 每次修改完代码后，程

现在我们一说到“面向对象编程”似乎感觉就是编程的全部，实际上它是 20 世纪 60 年代就已经出现的一门“古老”技术，在 2000 年以后，随着 Java 和 .NET 等编程语言的出现，才逐渐开始在

在工作中，大家是否曾遇到过下列情形？ 团队辛辛苦苦做出的软件产品，却被客户云淡风轻地评价一句：“这不是我想要的。” 在新的项目中，自己作为系统的主要设计者采用了很多新技术，却发现团队成员的技术水平参差

软件程序通常有两个层面的需求： 功能性需求，简单来说，就是一个程序能为用户做些什么，比如，文件上传、查询数据等； 非功能性需求，这个是指除功能性需求以外的其他必要需求，比如，性能、安全性、容错与恢复、

在工作中，大家可能常常会发现，很多人将 Java 设计模式、大学里学的高等数学和编译原理等，视为脱离实际工作的知识。 但不管是面试还是实际工作中，是不是经常听到大牛前辈们给“洗脑”，说设计模式很重要？

Unix 操作系统诞生于 20 世纪 60 年代，经过几十年的发展，技术日臻成熟。在这个过程中，Unix 独特的设计哲学和美学也深深地吸引了一大批技术开发人员，他们在维护和使用 Unix 的同时，Un

一、解决真实问题很重要 先给你讲个故事。多年前刚参加工作时，刚转正不久就被派到客户现场解决一个紧急问题，对于一个刚入职场的新人小白来说，内心其实是非常惊慌无措的。 刚开始还算顺利，前辈同事们已经大致定