当我们在软件设计中想应用设计模式时，往往是凭借设计模式的名字和需求有点类似，之后就尝试着将模式生搬硬套到其中。而真正去理解设计模式往往变得比较困难，很多书籍也仅仅是用不同方法来降低模式记忆的强度。难道设计模式不能从更加细微的层面去理解吗？当然可以，设计模式就像可以再分解的化合物一般是可在分解，这种再分解后的模式叫做元素模式（elemental design
patterns , EDP）。
元素模式重申了一个非常重要的思想：模式是概念，而不是结构。GoF也这样认为：“假设某语言是面向过程的语言，那么它可能就会拥有一批被我们称为‘集成’、‘封装’和‘多态’的设计模式。”，显然GoF认为模式是语言无关的概念。在面向对象语言中可能已经有了“封装、集成和多态”的概念，但在面向过程的语言中同样可以通过设计模式达到这些概念的效果。两者不同的是，或者不同语言间不同的是，在一种语言中一些概念已经根深蒂固的被深入的理解，甚至是内嵌到了语言特性中，在另一种语言中他们却尚未被充分理解，但可以用模式的结构协助我们理解。
那么元素模式是通过什么方式分解出来的呢？我们阅读设计模式相关文献可以了解到设计模式涉及11个方面：意图（intent）、动机（Motivation）、适用性（applicability）、结构（structure）、参与者（participants）、合作（collaborations）、结果（consequences）、实现（implementation）、示例代码（samples
code）、已知应用（known uses）、相关模式（Related patterns）。设计模式是特定语境下的常见问题的常用解决方案,权威形式的设计模式,它的大部分片段都可以很容易的归为三类:解决方案、问题以及语境。我们可以将上文提到的模式的组成片段整理到模式定义的这三个类别中去，如下表所示。
|
解决方案 |
结构 实现 示例代码 |
|
问题 |
意图 动机 已知应用 |
|
语境 |
应用范围（适用性） 结果 相关模式 |
上表的三个分为并没有将设计模式涉及的角参与者（participants）和协作活动（collaborations）包含在内。而由于这两者存在的环境（语境）中常常存在问题，而他们有反映着问题的现象，同时它们还构成了问题解决方案的一大部分，所以这两者贯穿于上表的三种类别。总之参与者和协作活动在上表描述的设计模式的三个分支的交叉点上描述着设计模式的组成部分，以及这些部分的关系。由此可见关系构成了设计的核心。
参与者和协作活动所表述的关系会有很多种，从简单到复杂，那么什么样的关系才是元素模式所真正关心的呢？既然设计模式可以进一步分解，就应该将其分解到最小单元，而两个事物间最简单的关系则是单一关系。从而得知我们可以将设计模式中的复制的关系网分解为这种单一关系，而这种关系往往是方法对另一个方法的调用依赖关系，我们称之为关键关系。元素模式就是由此而逐渐演化推导而来的，也是后续深入理解设计模式的基础。