DRY 编程困境答案

【问题标题】：DRY programming dilemmaDRY 编程困境
【发布时间】：2010-05-03 09:44:03
【问题描述】：

情况是这样的：

我正在创建一个可以写入文件的 Logger 类，但 write_to_file() 函数作为静态函数位于辅助类中。

我可以调用该函数，但 Log 类将依赖于辅助类。

依赖不好吗？

但如果我可以让它使用辅助函数，那么拥有辅助函数的意义何在？

这里应该优先考虑什么：使用辅助函数并且必须在任何地方都包含这个辅助类（但其他 99 种方法不会有用）或者只是复制并粘贴到 Log 类中（但是如果我已经这样做了 100 次并且然后进行更改，我必须更改 100 个位置）。

分享你的想法和经验！

【问题讨论】：

标签： design-patterns

【解决方案1】：

依赖本身并不坏；他们只需要得到有效管理。听起来您可能有一个具有多个职责的辅助类（100 个方法对我来说似乎很多），所以可能需要将该辅助类拆分为多个类。

另一种选择是创建一个 IFileWriter 接口，该接口具有您需要的一个辅助方法。然后，让助手类实现该接口，并让记录器依赖于接口而不是具体的助手类。这样，如果您有时间重构辅助类，则记录器不必更改。

【讨论】：

【解决方案2】：

我认为你让事情变得比实际更复杂。

如果有 2 个或更多类需要该功能（现在在帮助类中），那么让它在那里，没有问题。

如果目前只有记录器使用此功能，则将其移至记录器类。如果其他班级需要，您可以随时将其移回。

拥有辅助函数有什么意义？

如果您有一个可以被许多不同的类使用（并且肯定会使用）的函数，并且这个函数不依赖于调用者状态，那么它可以是一个辅助函数。像数学运算（sqrt 等）或不同的格式化程序。

【讨论】：

或者把助手类一分为二。
我不会说我让它变得复杂。只是想看看一个人应该优先考虑什么或什么是好的编程哲学:) 我想我解决了它。如果类使用文件函数，我可以有一个文件助手类，并且只包含那个。所以会有多个助手类，而不是一个超级助手类:)

【解决方案3】：

这也取决于你希望你的 logger-class 有多灵活。如果您认为可能稍后将日志输出写入网络而不是文件，那么将日志条目写入接口的过程抽象（例如LogEntrySink）可能是明智的。然后您可以将不同的接收器注入您的记录器（例如FileWriterSink）。这使您能够让一个记录器使用不同的输出方法，而无需稍后更改任何代码。

【讨论】：

是的，我已经想到了：我有 DatabaseLog、FileLog 和 ScreenLog。每个人都将日志写入他们的层。

【解决方案4】：

您的日志记录类应该是完全独立的，原因如下：

重用目的。
确保日志记录代码中的错误不会影响系统的任何其他部分。
系统其他部分的错误不会显示为日志错误。

您最不想要的是最后两点中的场景。所以如果你有一个日志到文件记录器，我建议你不要依赖任何文件相关的类，这些类是你的记录器类中应用程序代码的一部分。

【讨论】：

但是我必须在所有写入文件的类中重新创建 write_to_file 函数。如果我想更改我的代码，我必须在所有地方进行更改。 logger类依赖于iLog、LogFactory等。在编程中，你永远不可能有一个独立的类。所以我认为最好在这里使用辅助函数并将其包含在包中。那么所有其他类也可以使用这个。只是我的想法，当然没有对错。
ILog 是一个正确的接口吗？在这种情况下，文件记录器是一个实现而不是依赖项。 LogFactory 提供了文件记录器实现的实例，这些不是依赖项。应用程序代码仅依赖于 LogFactory（这是依赖注入的一种用例）和 ILog 接口。 ILog 实现不应依赖于应用程序代码才能保持 DRY。对记录器的更改可能会导致应用程序代码被更改，并且这些更改会破坏应用程序，反之亦然。
也就是说，如果您有一个在许多应用程序中使用的文件处理库，那么您的记录器可能会依赖它，只要它具有稳定的 API。但是，嘿，这都是相对的，对你有用的才是最重要的。