问题标签 [anti-patterns]

给定一个像这样的类层次结构： 一个包树 是否有一个有助于创建对象的类是个好主意？Ei 一个类，其方法对应于可以创建的每个类（方法 equals() 返回一个 CompareCriteria 例如）。我看到的优点是它会隐藏复杂的继承结构，并且会减少依赖关系。

类层次结构和构造函数是相关的。来自子类的参数需要传递给它们的父类。

所以，在 Python 中，我们最终会得到这样的结果：

想象一下这有十几个子类和大量参数。添加新参数变得非常繁琐。

当然，可以完全放弃命名参数并使用 *args 和 **kwargs，但这会使方法声明模棱两可。

在 Python (2.6) 中是否有优雅地处理这个问题的模式？

“优雅”是指我想减少参数出现的次数。a、b、c、ka、kb、kc 都出现了 3 次：在 Child 构造函数中，在对 Parent 的 super() 调用中，以及在 Parent 构造函数中。

理想情况下，我想为 Parent 的init指定一次参数，而在 Child 的init中只指定附加参数。

我想做这样的事情：

不幸的是，这不起作用，因为 4、5、6 最终分配给了 kd、ke、kf。

是否有一些优雅的 python 模式可以完成上述操作？

我有一个相对复杂的泛型类型（比如Map<Long,Map<Integer,String>>），我在类内部使用它。（没有外部可见性；它只是一个实现细节。）我想将它隐藏在 typedef 中，但 Java 没有这样的工具。

昨天我重新发现了以下成语，并很失望地得知它被认为是一种反模式。

当类型被隐藏并且不构成库 API 的一部分时（在我的阅读中这是 Goetz 对使用它的主要反对意见），这是否有任何理由？

我一直认为仅仅为了保持常量而开设一个类是一个糟糕的设计。但最近，我尝试用谷歌搜索它，发现只有将接口作为常量是不好的反模式——没有提到使用常量类。

我的观点是，由于一类常量与全局变量实际上并没有太大区别，这就是为什么我反对它并倾向于重构这些类。它创建了一类完全没有上下文的数据。这些常量最好与实际使用它们的任何东西联系起来，为它们提供上下文和意义，以及将它们封装在一个类中。

其他人怎么想？

什么是最常见的Ruby on Rails 反模式以及如何避免它们？

根据这篇文章，需要 ruby​​gems 是一种反模式。

争论似乎可以归结为：

当我使用您的库、部署您的应用程序或运行您的测试时，我可能不想使用 ruby​​gems。当您在代码中需要“rubygems”时，您将无法做出该决定。我不能不要求 ruby​​gems，但你不能一开始就要求它。

但是，当您创建并与其他人共享代码库时，不能对您“需要”的任何 Ruby 库提出相同的论点吗？

我最近无意中听到有人说数据传输对象(DTO) 是一种反模式。

为什么？有哪些替代方案？

作为一个 Git 新手，我意识到我一直在使用它，就好像它是 Subversion。例如，总是在 master 上工作，而不是在拉取更改之前在本地提交等。这通常会导致可避免的手动合并情况。使用 Git 的其他常见反模式是什么？

将参数传递给函数以选择函数的功能的名称是什么？

例如：

对比：

在数据库中，您有一个带有位字段的表，我们将该字段称为Active

在应用程序中，您有一个布尔变量，我们称之为NotActive

每次从表中获取字段时，在应用程序中您都切换了变量的含义。

另一个示例是数据库中名为Enable__yes__no的位字段，并且在您执行的代码中

最佳做法是保持相同的名称和相同的含义，但是上面的模式，你怎么称呼它？