是否有描述这种编码方法的反模式？[关闭]

我有一个代码库，程序员倾向于将其包装在没有意义的区域中。例如，给定一个错误日志，我们可以通过

ErrorLog.Log(ex, "friendly message");

他添加了其他各种方法来完成完全相同的任务。例如

SomeClass.Log(ex, "friendly message");

它只是转过身来并调用第一个方法。这增加了复杂性级别，并且没有任何额外的好处。是否有一个反模式来描述这一点？

只有在合理分布的情况下，才应将一些不良的编码习惯称为反模式。

其余的我们只称之为“垃圾代码” ...

如果我要为这个特殊的习惯建议一个名字，那就是“强迫症” ：-)

不，这不是反模式，但我会提出以下问题。

违反单一责任原则

SRP说，一堂课应该有一个改变的理由。添加记录器方法意味着，如果应该更改日志记录逻辑，则也必须更改类。

违反is-a关系

基类不是可以在其中添加几种便捷方法的工具箱。

这样做可以有效地将所有继承的类耦合到基类具有的实现。

将其与组成进行比较。

并不是说这可以接受，但这可能只是一个未完成的重构。也许SomeClass.log（）拥有自己的逻辑，并且首先被实现。后来他们意识到应该使用ErrorLog.Log（）。因此，与其更改100个调用SomeClass.Log（）的位置，不如将它们委托给ErrorLog.Log（）。我个人将更改对ErrorLog.Log（）的所有引用，或者至少注释SomeClass.log（）来说明为什么委派它的方式。

只是要考虑的事情。

我想到了“千层面密码”一词，尽管显然它对不同的人意味着不同的意思。我的解释一直都是“为了分层而分层”。

我不确定将其描述为对单一责任原则的冒犯，因为如果ErrorLog方法签名（由SomeClass调用的方法）发生更改，则调用此方法的每个客户端代码都会失败。

显然有一种使用继承的方法（或使类需要进行日志记录以实现日志记录接口）。

或者我们可以将其视为“可教的时刻” :)

您的开发人员可能只是个好主意。假设您希望所有业务对象都具有智能日志记录功能。您可以定义：

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

现在，在对象内部，您可以使用ErrorLog对象实际执行日志记录，而SomeClass代码将特定于对象的值添加到日志消息中。然后，您可以进一步扩展您的日志记录API，以实现基于文件，基于数据库或基于消息的日志记录功能，而无需动您的业务对象。

我不确定这会自动成为邪恶。

如果您要调用SomeClass.Log，那么它肯定是邪恶的，但是如果仅从WITHIN SomeClass中使用Log，则会减少耦合，我可以接受。

实际上，这在某些编码样式中非常普遍，而思路的基础本身并不是反模式。

这很可能是某人在不需要更广泛的代码库的情况下就必须进行编码的结果：“好的，此代码需要记录一个错误，但是该功能不是代码的主要目的。因此，我需要一个可以做到这一点的方法/类为了我”。这是一个很好的思考方式。但是，他们在不知道ErrorLog存在的情况下创建了SomeClass。然后，他们在以后找到了ErrorLog，而不是替换所有使用的方法，而是将方法称为ErrorLog。那就是问题所在。

偶然的复杂性是在计算机程序或其开发过程中出现的复杂性，它对要解决的问题不是必需的。虽然本质上的复杂性是固有的和不可避免的，但偶然的复杂性是由解决问题的方法所引起的。

http://en.wikipedia.org/wiki/Accidental_complexity

可能是对Facade模式的滥用/误解。我在使用过的代码库中看到过类似的事情。开发人员经历了一个阶段，他们在不了解OO设计的总体原理的情况下对设计模式感到疯狂。

滥用Facade模式会导致整个应用程序层的抽象级别模糊。

程序员正在做的事情是包装一些代码，以便它不直接依赖于日志记录模块。没有更具体的信息，就不可能给出更具体的模式。（您认为这些包装程序无用，如果没有更多信息，就无法同意或不同意。）

可能属于的模式是Proxy，Delegate，Decorator，Composite或与打包，隐藏或分发调用有关的某种模式。这可能是处于不完整发展状态的事情之一。

我可以想象这是文化差异。在此特定代码库中可能有重复功能的充分理由。我可以想象写的容易是这样的原因。我里面的Python程序员仍然会说这很不好，因为“ 应该有一种-最好只有一种-显而易见的方式。 ”，但是一些Perl家伙可能已经习惯了这样的事实：“ 有不止一种的方式 ”。