在最开始，可将范式想象成一种出格智慧、可以或许自我适应的手法，它可以办理特定范例的问题。也就是说，它雷同一些需要全面认识某个问题的人。在相识了问题的方方面面今后，最后提出一套最通用、最机动的办理方案。详细问题或者是以前见到并办理过的。然而，从前的方案也许并不是最完善的，各人会看到它如安在一个范式里详细表达出来。
尽量我们称之为“设计范式”，但它们实际上并不范围于设计规模。思考“范式”时，应离开传统意义上阐明、设计以及实施的思考方法。相反，“范式”是在一个措施里详细表达一套完整的思想，所以它有时大概呈此刻阐明阶段可能高级设计阶段。这一点长短常有趣的，因为范式具有以代码形式直接实现的形式，所以大概不但愿它在初级设计可能详细实施以前显暴露来（并且事实上，除非真正进入那些阶段，不然一般意识不到本身需要一个范式来办理问题）。
范式的根基观念亦可当作是措施设计的根基观念：添加一层新的抽象！只要我们抽象了某些对象，就相当于断绝了特定的细节。并且这后头最引人注目标念头就是“将保持稳定的对象身上产生的变革孤独出来”。这样做的另一个原因是一旦发明措施的某部门由于这样或那样的原因大概产生变革，我们一般都想防备那些改变在代码内部繁衍出其他变革。这样做不只可以低落代码的维护价钱，也更便于我们领略（功效同样是低落开销）。
为设计出成果强大且易于维护的应用项目，凡是最坚苦的部门就是找出我称之为“领头变革”的对象。这意味着需要找出造成系统改变的最重要的对象，可能换一个角度，找出支付价钱最高、开销最大的那一部门。一旦发明白“领头变革”，就可觉得本身定下一个核心，环绕它展开本身的设计。
所以设计范式的最终方针就是将代码中变革的内容隔分开。假如从这个角度调查，就会发明本书实际已回收了一些设计范式。举个例子来说，担任可以想象成一种设计范式（雷同一个由编译器实现的）。在都拥有同样接口（即保持稳定的对象）的工具内部，它答允我们表达行为上的差别（即产生变革的对象）。合成亦可想象成一种范式，因为它答允我们修改——动态或静态——用于实现类的工具，所以也能修改类的运作方法。
在《Design Patterns》一书中，各人还能看到另一种范式：“担任器”（即Iterator，Java 1.0和1.1不认真任地把它叫作Enumeration，即“列举”；Java1.2的荟萃则改回了“担任器”的称号）。当我们在荟萃里遍历，逐个选择差异的元素时，担任器可将荟萃的实施细节有效地埋没起来。操作担任器，可以编写出通用的代码，以便对一个序列里的所有元素采纳某种操纵，同时不必体贴这个序列是如何构建的。这样一来，我们的通用代码即可陪伴任何能发生担任器的荟萃利用。
