问题标签 [design-patterns]

我正在为我维护的应用程序开发自动回归测试套件。在开发自动化回归测试时，我遇到了一些几乎可以肯定是错误的行为。所以，就目前而言，我已经修改了自动回归测试以不记录失败——我的意思是，它故意让这种不良行为过去。

所以，我对这个网站上其他人的意见很感兴趣。显然，我将在我们的缺陷跟踪中添加一个错误，以确保此错误行为得到修复。但是是否有任何令人信服的理由（无论哪种方式）要么更改回归测试以不断指示失败，要么让回归测试中断并且在我们能够修复有缺陷的行为之前不失败？我认为这是其他类型问题中的六分之一，但我在这里问是因为我认为其他人可能会有不同的看法。

@保罗·汤布林，

明确一点——我从未考虑过删除测试；我只是在考虑修改通过/失败条件以允许失败，而不会在每次运行测试时都出现在我面前。

我有点担心由于已知原因导致的重复失败最终在 C++ 中被视为警告。我知道开发人员会在他们的 C++ 代码中看到警告并忽略它们，因为他们认为它们只是无用的噪音。我担心在回归套件中留下一个已知的失败可能会导致人们开始忽略其他可能更重要的失败。

顺便说一句，以免我被误解，我认为 C++ 中的警告是编写强代码的重要帮助，但从我遇到的其他 C++ 开发人员来看，我认为我是少数。

我已经阅读了最新的C# 语言规范中的部分方法，所以我了解这些原则，但我想知道人们实际上是如何使用它们的。是否有一种特定的设计模式可以从部分方法中受益？

可能重复：
是否有一种简单、优雅的方式在 Python 中定义单例？

在 Python 中实现单例模式的最佳方法是什么？似乎不可能像使用单例模式那样将构造函数声明为私有或受保护...

我听过/读过这个词，但不太明白它的意思。

我什么时候应该使用这种技术，我将如何使用它？谁能提供一个好的代码示例？

警告：我对编码和TextMate都比较陌生，所以如果我在这里遗漏了一个明显的答案，我深表歉意。

我做了很多 HTML/CSS 标记，有一些我经常使用的模式，例如表单、导航菜单等。我想要一种存储这些模式并在需要时快速插入它们的方法。

有没有办法使用 TextMate 做到这一点？

有谁知道论文/书籍/等。数据库的文档模式？例如，一个常见的经验法则是每个表都应该有一个主键，并且该键应该没有信息内容。所以我想知道是否有人写过关于设计关系数据库的设计模式的书或发表过论文？

@盖乌斯，

这就是数据库设计者需要权衡的问题——数据库结构的可能稳定性是多少？给定一个足够长的视野，没有什么是稳定的。或者反过来说，只要视野足够长，一切都会发生变化。代理键（理论上）不应该改变它的含义，因为它从一开始就没有意义。

我想在那个特定的设计场景中要考虑的另一件事是谁会看到主键？如果主键是最终用户实际需要参考的东西，那么让它成为他们可以理解的东西是有意义的。但是我想不出最终用户需要查看主键的许多情况。通常存在主键以允许数据库引擎加速某些操作。

我最初提出这个问题的想法是找到由比我更有经验的数据库设计人员编写的数据库设计设计模式，以便避免一些容易避免的错误。如果有人曾经编写过数据库设计反模式，那将会很有趣。

作为我自己的练习，我正在将一个示例程序翻译成各种语言。从 C# 开始，我有一个访问者模式界面，如下所示：

转向 ruby​​（或 python，或其他），我不再根据类型从编译器获得调度。我应该在访客本身中进行调度吗？

或者我应该在房间的不同专业中进行调度：

或者是否有另一个在动态语言中使用的首选习语？

如果我有一组数据库表（例如，在 Access 文件中），并且需要根据一个规则集验证该集合中的每个表，该规则集具有跨所有表的通用规则以及特定于一个或一个子集的单个规则表，有人可以推荐一个好的设计模式来研究吗？

具体来说，我想避免类似的代码：

另外，我决定使用 log4net 来记录所有的错误和警告，这样每个方法都可以被声明void并且不需要返回任何东西。这是一个好主意，还是创建某种ValidationException捕获所有异常并将它们存储在 a 中List<ValidationException>，然后在最后将它们全部打印出来会更好？

我确实找到了这个，看起来它可能有效，但我希望能找到一些代码示例来解决。有什么建议么？过去有没有人做过类似的事情？

对于某些背景，该程序将使用 C# 或 VB.NET 编写，并且表很可能存储在 Access 或 SQL Server CE 中。

说出在决定使用单例还是静态类时的设计注意事项。在这样做的时候，你有点被迫对比两者，所以你能想出的任何对比对于展示你的思维过程也很有用！此外，每个面试官都喜欢看说明性的例子。:)

我读过的几乎每一本 Java 书籍都谈到了使用接口作为在对象之间共享状态和行为的一种方式，这些对象在第一次“构造”时似乎并不共享关系。

然而，每当我看到架构师设计应用程序时，他们做的第一件事就是开始对接口进行编程。怎么会？您如何知道将在该接口中发生的对象之间的所有关系？如果您已经知道这些关系，那么为什么不扩展一个抽象类呢？