使用“混合”语言进行设计：面向对象的设计还是功能编程？

在过去的几年中，我喜欢使用的语言变得越来越“实用”。我现在使用的是一种“混合”语言：C＃，F＃，Scala。我喜欢使用与域对象相对应的类来设计我的应用程序，并使用使编码更容易，更简洁和更安全的功能功能（尤其是对集合进行操作或传递函数时）。

但是，当涉及到设计模式时，这两个世界会“冲突”。我最近遇到的特定示例是观察者模式。我希望生产者在创建或更改项目时通知其他一些代码（“消费者/观察员”，例如数据库存储，记录器等）。

我最初是这样“功能性地”完成的：

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

但是我现在想知道是否应该使用更多的“ OO”方法：

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

两种方法的优缺点是什么？我曾经听过一位FP专家说，那里的设计模式仅是由于语言的局限性，这就是为什么功能语言很少的原因。也许这可能是一个例子？

编辑：在我的特定情况下，我不需要它，但是..您将如何以功能方式实现“观察者”的删除和添加？（即，您将如何实现模式中的所有功能？）例如，仅传递一个新函数？

这是两种不同方法的一个很好的例子，它们带有在调用对象关注的边界之外执行任务的概念。

虽然在此示例中很明显，您应该采用功能方法，但是通常，它实际上取决于被调用对象必须表现出的行为有多复杂。如果确实是一个复杂的行为问题，您会发现自己经常重新应用类似的逻辑，而函数生成器无法用来清楚地表达它，那么您可能想要进行类组合或继承，在这里您将在临时基础上具有更大的自由重用和扩展现有行为。

不过，我确实观察到的一种模式是，通常开发人员最初会采用功能性方法，并且只有在出现对更细粒度行为的需求时，他们才决定采用基于类的方法。我知道，例如，一旦好处和需求变得显而易见，Django就从基于函数的视图，模板加载器和测试运行器转变为基于类的视图，但是在此之前并没有。

该功能版本更短，更易于维护，更易于阅读，并且通常在几乎所有可以想到的方面都非常优越。

尽管要克服所有模式，但许多方法要弥补OOP中缺少的功能，例如观察者。这些在功能上要好得多。

您的“ FP专家”部分正确；许多OO模式都是做功能性工作的黑客。（他声称这就是很少有FP语言似乎充其量可疑的原因。）Observer和Strategy模式正在尝试模仿一流的功能。访客模式是一种模拟模式匹配的技巧。您IItemObserver只是变相的功能。假装它与其他任何需要某项功能的功能都不相同，那么您什么也买不到。

对象只是一种数据抽象。本文将有助于阐明该主题。对象可能有用，但是重要的是要认识到它们并不适合所有事物。没有二分法。只需为合适的工作选择合适的工具，而函数式编程绝不需要您放弃对象。除此之外，函数式编程不仅仅是使用函数。这也与最小化副作用和突变有关。

我真的不能回答这个问题，因为我不擅长函数式语言。但我认为，只要您拥有的东西有效，您就应该较少关注方法。据我了解，只要您将来不添加更多侦听器或在执行过程中不更改侦听器，就可以在此处很好地跳过Observer模式。

我不同意设计模式弥补了面向对象语言中的“局限性”。它们在那里是为了充分利用OOP功能。多态和继承是功能，而非限制。设计模式利用这些功能来促进灵活的设计。您可以在OO中制作绝对非OO程序。您可以非常小心地编写一个完整的程序，其中包含无状态的对象，类似于FP。