软件设计问题是否有规范或有利的分类？

Question

这个问题似乎相当模糊，所以让我给出一些背景：

我对设计模式的概念作了一些思考，偶然发现了“四人帮”所使用的分类：

• 创造模式
• 构造模式
• 行为模式

由于设计模式是为了解决常见的设计问题，所以分类不仅适用于模式，也适用于潜在的问题。

不知何故，分类似乎是有意义的，我发现很难找出一个设计问题，不能放在这些类别之一。另一方面，我觉得这有点武断。

创造不是一种行为吗？如果某物被归类为行为或结构，这不是有时取决于观点吗？为什么有造物模式，却没有“毁灭”模式？

这个分类是“四人帮”的发明，还是以前用过？它能从某种理论中推导出来吗？还有其他选择吗？

虽然这个问题与我的前一次有关，但它有两个不同之处：

• 它是关于分类方案，而不是关于模式本身。
• 它不是关于模式，而是关于希望通过模式解决的设计问题。

Answer 1

基本的误解是，对于一个给定的问题，有一个给定的模式。

模式不是关于如何编码的课程。它们是我们用来描述我们在代码中识别的模式的词汇。

我可以以一种避免当前任何文档化模式的方式解决任何问题。如果我这样做的话，我将很难向其他人解释我的代码是如何工作的。

的确，模式选择受到问题的影响，但也受到语言(以及它的缺陷)的影响，但它们大多是个人风格的问题。

任何模式的集合都是不完整的，因为任何人都可以创建一个新的模式。你学到的只是那些受欢迎的。

那些受欢迎的人很高兴知道，因为我可以告诉你们：“哦，那个班级是一个装饰师，你知道，装饰师的模式？”而不必详细介绍功能组合、接口和委托。

造物只是指这些模式的意义在于构造(初始化)某个对象。

structure只是指这些模式的目的是创建某种数据结构。

行为只是指这些模式的意义在于按照某些用例所需程序的行为方式行事。

这些是与分类问题无关的非常不同的目标。他们是解决一个问题的一部分。如果问题是从a点到b点，这些方法告诉你如何建造一辆汽车，导航地图，并获得驾驶执照。

这一切都很好，但是如果你愿意的话，你可以走路。

Answer 2

软件吞噬了这个世界。因此，你的富有挑战性的问题听起来就像把宇宙分割成预先定义的乐高片。不同的作者对这些作品有不同的看法：

• GoF使用了三个主要类别来解决常见的类设计问题。
• Martin写了一本关于"企业应用体系结构的模式“的书，它确定了设计商业软件体系结构的不同类型的模式。它分为领域逻辑、数据源、对象关系映射、元数据映射、web表示等.
• POSA (又名"Patten“)是Buschmann & al的4或5本书的集合，它为并发对象管理、资源管理、系统和分布式计算等特定问题确定了体系结构模式。
• 有许多关于专业模式(例如软件集成模式)的书籍。
• 编程语言还附带了一些可以被视为低级模式的成语(例如，C++中的RAII，或C++、Java和其他面向对象语言中的输入/输出流)。

问题是，这些分类并不都在同一个抽象级别上。它们可能会进一步重叠。

因此，找到所有软件问题的一般分类，就像寻找一种最适合所有编程需求的通用编程语言一样雄心勃勃。或者一种通用的软件分析方法，它可以将任何编程问题分解为预定义的部分。

这是不可能的:正如这些书所显示的那样，这可能是为了解决已知的问题。但是，在西南地区的发展中有许多新的领域或新技术，不同的部分之间有如此多的相互作用。恐怕你找不到这么笼统的分类。

Answer 3

GoF模式不是软件模式的全面列表，也不是用来提供解决计算问题或编写应用程序的通用框架。

在大多数情况下，GoF模式是弥补某些编程语言不足的方法，这就是它们的全部。

GoF模式的三种类型：

• 创造模式
• 构造模式
• 行为模式

仅仅是作者为他们的书补上的术语，这样他们就可以在概念上把模式划分成不同的桶。