问题标签 [anti-patterns]

似乎以前没有问过这个确切的问题，所以我会开火：

我们大多数人都熟悉反模式的概念。然而，避免实现反模式原则上可能会反其道而行之，并导致问题本身。例如，“委员会设计”有一个反例，我称之为“Maverick 设计”——其中一个重要功能的设计被交给个人去做他们认为最好的事情，目的是审查他们稍后的工作并决定是否应该完成或进行另一次迭代。这在实践中需要更长的时间，因为团队的其他成员都忙于其他事情，并且最终可能会得到一个对任何人都没有用的功能，特别是如果 Maverick 本身不是经验丰富的最终用户。

有没有人有更多反模式反例的例子？

我目前正在开发一个基于组件的 API，它是有状态的。顶层组件每个都实现了大约十几个接口。

因此，库存的顶级组件位于抽象实现堆栈的顶部，抽象实现又包含多个混合实现并实现多个混合接口。

到目前为止，一切都很好（我希望）。

问题是基本功能实现起来非常复杂（5 层基类中有 1000 行），因此我不希望组件编写者自己实现接口，而是扩展我的基类（所有锅炉车牌代码已经写好了）。

因此，如果 API 接受接口而不是对我希望组件编写者扩展的抽象实现的引用，那么我将面临实施者不会执行其他代码区域所要求和假定的验证的风险。

因此，我的问题是，有时使用抽象实现引用而不是对其实现的接口的引用来参数化 API 方法是否有效？

您是否有一个使用这种技术的设计良好的 API 的示例，或者我是否试图说服自己采用不好的做法？

假设我有一个在某些机器上运行 24x7 的库。即使代码坚如磐石，硬件故障也迟早会触发异常。我想为这样的事件设置某种故障保护装置。一种方法是编写封装每个 api a 的包装函数：

然后库的调用者重新启动整个线程，如果 returnCode 错误则重新初始化模块。

事情可能会大错特错。例如

如果 try 块（或 libraryAPI1()）有：

如果 func2() 抛出异常，x 将永远不会被释放。同样，文件损坏也是一种可能的结果。

你能告诉我在这种情况下还有什么其他可能出错的地方吗？

在类设计中，如果一个方法调用同一个类中的另一个方法（例如，3个方法调用同一个类中的1个方法）是不是一个坏习惯。

谢谢

当可以线性解决时，我很难回忆起用二次复杂度做某事的名称。

例如，使用get-by-index函数来迭代链表而不是仅使用 anext-element是这种反模式的典型情况。

我认为是“某事画家”，比喻一个人正在画一条路，但没有随身携带油漆桶，每次需要重新填充画笔时都必须回到起点。

干杯。

我在一个 Web 应用程序框架中工作，其中一部分由许多服务组成，所有服务都作为单例实现。它们都扩展了一个服务类，其中实现了单例行为，看起来像这样：

现在，如果我有一个像这样实现的名为 FileService 的类：

...调用 FileService::getInstance() 不会像我想要的那样产生一个 FileService 实例，而是一个 Service 实例。我认为这里的问题是服务构造函数中使用的“self”关键字。

还有其他方法可以在这里实现我想要的吗？单例代码只有几行，但我仍然希望尽可能避免任何代码冗余。

在许多不同公司中使用不同版本的 .NET 编写的许多遗留系统上工作，我一直在寻找以下模式的示例：

对于任何知道 .NET 中内存管理如何工作的人来说，这种代码是非常不必要的。垃圾收集器不需要你手动分配null来告诉旧对象可以被收集，分配也不需要null指示 GC 立即收集对象。

这种模式只是噪音，使得更难理解代码试图实现的目标。

那么，为什么我一直在寻找这种模式呢？有学校教授这种做法吗？是否有一种语言需要将null值分配给本地范围的变量才能正确管理内存？明确分配null我没有意识到的还有一些额外的价值吗？