scala - 将 OOP "decorator"重构为释放 monad 结构

Question

我有一些“遗留”Scala 代码(类 Java)，它执行一些数据访问。有一个装饰器可以跟踪 DAO 方法(收集指标)的使用情况，如下所示:

class TrackingDao(tracker: Tracker) extends Dao {
    def fetchById(id: UUID, source: String): Option[String] = {
        tracker.track("fetchById", source) {
            actualFetchLogic(...)
        }
    }
    ...
}

我正在尝试将其建模为一个 Free monad。我为 DAO 操作定义了以下代数:

sealed trait DBOp[A]
case class FetchById(id: UUID) extends DBOp[Option[String]]
...

我看到两个选项:

a) 我可以制作两个采用DBOp 的解释器，一个执行实际的数据访问，另一个执行跟踪，然后将它们组合在一起或者
b) 我使 Tracking 成为显式代数，并使用 Coproduct 在相同的 for 组合中使用它们，或者
c) 完全不同的东西!

第一个选项看起来更像是一种“装饰器”方法，它与 DBOp 相关联，第二个是更通用的解决方案，但需要显式调用“跟踪”代数。

此外，请注意原始 fetchById 调用中的 source 参数:它仅用于跟踪。我宁愿将它从 API 中删除。

真正的问题是:如何为跟踪建模？

Answer 1

从你的问题中还不完全清楚，但如果跟踪是一种环境效应，当你执行数据库访问时应该“发生”并且 source 只是用于跟踪目的的参数，你可能不会必须用您的自由语言提及它。您可以使用您现在拥有的 ADT 并将其解释为 (Tracker, Source, OtherStuff) => IO[A] 例如，因此您得到的是一个函数，该函数将生成一个程序来执行 DB一旦你给它一个 Tracker 和源以及你需要的任何其他东西(例如数据库连接)就可以访问，并且跟踪实现对解释器来说是完全私有(private)的。这使您可以在编写数据库程序时完全不考虑跟踪。

另一方面，如果您确实需要讨论业务逻辑中的跟踪，那么我们可能需要更多关于拥有多个Tracker 和source 及其介绍和使用方式。可能需要副产品或扩展语言或嵌套语言来处理您需要表达的内容。