一段代码，如果可重用并适用于不同的上下文，可以归类为一种模式吗？

Question

什么构成模式？如果我有一个可重用且可以应用于其他类似情况的模板/代码，它可以被称为模式吗？

以下是我创建的内容。它是处理条件结构的二元方法。我在表中具有复合的字段，即它包括3个或更多个其他子字段，每个子字段具有真值或假值。

现在，我将表示真/假值的子字段表示为0和1.这些字段在基于Web的应用程序中显示为用户的下拉列表。组合这些字段以形成包括8位的字节值，前3位具有0或1的值，用户选择为假或真。如果用户选择所有字段为true，则主字段的值为7，如果他选择所有字段为false，则主字段的值为0且类似。

主字段表示现有表中的一列。此代码的优点是，由于需要新的子字段，因此无需在表中添加新列。用户界面将为每个新子字段添加一个额外的下拉列表。

此代码可重复使用，可应用于不同的上下文。这可以归类为模式吗？

Answer 1

来自设计模式：

“观点影响一个人对什么是模式的解释。一个人的模式可以是另一个人的原始构建模块。”

它还说，一般来说，模式有四个基本要素：

• 名称
• 问题
• 溶液
• 后果

我认为有理由说，即使是非常有经验的程序员称之为原始构建块的一些技术也可以被视为初学者的模式。如果我正在教一个全新的程序员，我想我会立即开始讨论模式，将它们与语言结构相关联，如循环（for ... next，do ... while等）和错误处理（尝试...捕获，错误goto等）然后介绍你可以创建和使用自己的模式的想法（例如懒惰的初始化，保护条款）。

我在某处读到真正有用的模式最终会被合并到语言中，所以我总是想象for ... next循环开始作为汇编程序模式。所以今天的设计模式是明天的原始构建模块是明天的语言特征。

Answer 2

有langage模式，但大多数模式是指设计而不是语言特定的任何内容。

你描述的东西我称之为组件。

另外，在列中存储多个值可能违反了规范化的准则。从长远来看，如果你每个值使用一列，可能会更容易。

请参阅this question的第一个答案，了解规范化的说明。

Answer 3

嗯，设计模式通常比这更抽象。毫无疑问，这里有一个潜在的模式。但是，存储方式的详细信息将变为更多实现细节，而不是模式的一部分。现在，您可能会深入思考并辨别您正在使用的基础模式。不过，对我来说现在深思熟虑已经有点晚了。 :)但是，你采用的是一种元数据方法，它与Entity Attribue Value之类的东西有一些关系（不过，这不是EAV的情况）。

Answer 4

模式不是它作为方法的实际代码。猜测这可能是某种模式...我想说模式往往是逻辑/方法的基础，它们可以回归到基本形式，并且在许多情况下可以用于许多人。

不确定您的方法是否是其中之一？！

Answer 5

不是真的。模式是一种解决方案a way to approach a common programming problem，而不是一段代码。

您所描述的内容更好地命名为执行某项操作的模块或库（甚至是函数/子例程）。

Answer 6

你拥有的是一个组件。模式是一种用于构建组件的技术，并不特定于任何特定的问题域。