软件过失的23种模式

这是程序员真的使用的设计模式

> I’ll get the new guy to figure it out [WikiCommons]

自从四人帮带着石碑从山顶跌落以来，生活就一直不一样。 他们为我们提供了23种规范的设计模式，为您甚至不知道遇到的问题提供了有希望的解决方案。 有些人认为这些模式是讨论复杂问题和描述经过测试的解决方案的一种方式-一种可以帮助防止程序员重新发明轮子的通用语言。 其他人只是把它们像魔术般的尘土一样撒在可疑的代码上。 但是每个人都同意设计模式是一个非常重要的主题。

但是也许我们犯了一个错误。 与其发明名称来描述编码人员创建的常见解决方案，不如我们应该为我们留下的最流行的灾难创造术语。 因为唯一比设计模式更流行的是这些，所以23种持久的软件过失模式。 去看一下。 您对实践有罪吗？

责任链模式

当您的代码受到批评时，爬上方便借口的阶梯。 测试人员错过了该错误。 用户使用软件错误。 规格要求它是这种方式！ 工具坏了！

宽恕模式

当您在一段无法理解的代码之前加上道歉注释，即 //这是旧代码 或 // TODO：修正此古怪的算法。

原型推广模式

您编写了一个快速而肮脏的原型。 老板喜欢它，并希望使其成为真正的产品。 但是正确地重写它并不能使您及时到达那里。 尽快获得所需的唯一方法是重新编译原型并将其称为发行版。

不朽模式

如果代码的寿命足够长，则无需再对其进行修复。 毕竟，更改旧代码只是在问问题。 （与僵尸模式密切相关，当您保留旧代码”以防万一”时。）

装饰器模式

当您添加设计模式以使您的解决方案看起来更专业时。 类似于您用塑料碗水果装饰房子的方式，并且同样不可食用。

随机戳模式

您的代码无效。 也许更改一些随机细节并重新编译？ 你永远不会知道…

克隆模式

Procrustes模式

Procrustes是希腊神话中的客栈老板，他在睡觉时将顾客的腿砍掉了，因此最好放在他的床太短的地方。 在软件开发中，Procrustes模式是您为计划设置一个失效日期，然后将软件功能缩减为适合的时间。

金色沉默模式

不要让异常破坏您的代码。 安静地抓住它们并继续前进。 如果您捕获基本异常类以抑制所有错误（称为停电模式），则将获得加分。

道歉模式

与金色沉默模式类似，不同之处在于您通过无意义的错误消息和堆栈转储将异常 告给用户。 （看，我们毕竟没有忽略它！）

追溯形式化模式

首先编写程序，然后编写规格。 这样他们总是匹配的。

自酿模式

可能有一些库可以完成我们想要做的事情，但是有人不信任/理解/知道它们。 我们将建立自己的。 质量示例：自制加密。

保险模式

使代码足够奇怪，以至于他们总是需要您对其进行解密。 如果您以”干净代码”的名义遗漏所有注释，则可以得到加分。

特殊情况模式

如果发生这种不可思议的条件/值，则可以摆脱您所处的任何控制结构。 这是软件增强的一种模式–当您想尽快更改现有程序时会出现。 乘以特殊情况，乘以乐趣。

Wall O’Buttons模式

当开发人员临时使用用户界面时会发生什么。

积木模式

在整个结构崩溃之前，您可以进行多少更改？ 也称为变更瘫痪模式。

它来自上方模式

这个无意义的功能必须保持原样，因为它是从存在的能力中提出的。 此模式使所有调查短路，并胜过所有其他模式。

狂野西部模式

每个人都选择自己的验证规则和域逻辑以在各个时间点执行。 您永远不知道坏数据可以传播多远。

上帝对象模式

您从OO设计开始，但是由于某种原因，所有逻辑现在都属于一个非常特殊且非常庞大的类。

特殊顺序模式

如果您以正确的顺序使用它们，则每个操作都将完美运行。

裸体主义者模式

开始时，您的类将所有内容保密。 但是后来有人需要窥视某些东西，现在您不能侧身看，而不必看到每个物体完全暴露在外面的内部状态。

消失的异常捕获模式

当您的程序没有崩溃时，也没有响应。 它正在做某事，但是呢？

乐观模式

那不会发生。 用户不会这样做。 您将永远不会获得此类数据。 也称为模糊模式，因为您没有要测试的边缘情况

要获得生活中更多的编程幽默，请转到此处。 或者，要更认真地（但几乎是那么有趣）接受设计模式，请阅读是否该克服设计模式了？