在GoF23类设计模式之中,出了用于使用多态特征创建对象的五种设计模式之外,另有7个设计模式用于调整对象的数据结构和组织形式以获得更加复杂或者便利于当前使用状况的对象,这些设计模式并不着眼于对象的创建或者具体的使用阶段,他们的核心在于处理对象和对象以及抽象和具体实现之间的组合关系和结构,因此被称为结构型模式(Structral Pattern)。随着我们业务逻辑的扩张和处理情况的不断复杂化,随之而来的就是抽象结构复杂化和冗余臃肿的问题,这个时候因此引发的各种不兼容或者高耦合性就要使用这些设计模式妥善处理。
在所有的GoF23种设计模式之中有5类设计模式的作用机制产生于“创建一个抽象的具体实现”阶段,也就是将类对象进行实例化的阶段。这些设计模式从构造目的上分为一类:创建型模式(Creational Pattern)。有时候我们的业务逻辑的抽象程度很高而对应的实现手段或者实现场景非常复杂多变或者我们需要严格控制抽象到实现的流动的情况下我们就需要从创建对象的“根源步骤”去构造系统,并且其他的设计模式在现实业务场景之中或多或少需要与创建类设计模式进行组合。
相信大多数软件工程师的起点都是C语言,之后可能根据专注领域的不同接触了不同的面向对象编程语言,特别是Go或者Kotlin这种经常发愈发糖的语言更能够令人心情愉悦。然而不同于刚毕业的朋友们,无论是接触工程实际问题两三年的新手或者是深入实际业务的老鸟都会遇到一道厚厚的桎梏——为什么将实际业务需求转换成代码的过程总是这样蹭蹬?为什么项目总会变成一堆屎山代码?笔者在早期非常傲慢的认为这是能力孱弱的程序员们的借口和无病呻吟,直到眼睁睁看着自己投入无数精力的项目不可阻挡的变成了一坨大粪才重视起设计模式的问题。