刚开始看设计模式, 记得 Clojure 的报道里有吐槽过 OOP 没有证明很大的功效.
可原先很多问题不是用 OOP 的模式解决的么, 用 FP 怎么办?
我并没有用过clojure，我也并没有写过近年来常用的面向对象的范式（dependency injection, dependency inversion principle)。就连MVC，我也接触的不多。所以我的回答的有效性也许值得怀疑..
要深入了解某种程序范式以及相关设计模式的好，我觉得一个较为直接（但是比较耗时）的方式是，找一个典型的使用这种程序范式以及设计模式的库，然后学着使用它，并且尝试阅读其源代码。面向对象的话，有Java的JSP，Python的Django，C++的Qt，等等。函数式的话，有Haskell的mtl/parsec/lenses等等。
如果要深入比较两种程序范式以及相关设计模式的区别的话，我觉得可以这么做：还是先精通一个典型的使用某种程序范式和设计模式的库（比如C++的Qt），然后找到它在另一种语言里的binding（比如HQK），然后看看两者的写法有哪些不同。
一句话，如果脱离了应用，那么就很难真正去比较程序范式和设计模式的好坏。
针对你的问题，个人觉得没有唯一正确的答案，简单谈谈我自己的看法。
OOP是近些年来被广泛所了解、应用、推崇的一种设计思想。至于这种设计思想能否覆盖所有的应用场景？未必。否则也不会出现所谓的设计模式。设计模式更多是一种面向对象的设计方法——被人们所总结、实践证明的一种行之有效的OOP设计方法。偏激一点的说，设计模式一定程度上表明了OOP设计思想的缺陷与不足。
FP实际是很早之前就有的，只不过又被炒起来的一种设计思想，更多地关注设编程计过程中的抽象性、高度内聚性、无边界效应。个人觉得这也是应现代软件开发越来越复杂的需求而生的一种简洁的设计理念。
前面吐槽了一堆，可自行略过。回到提问的问题，我的答案：不要想着用函数式编程去解决OOP来解决的问题，尽管这样肯定是可以解决的(要不然在OOP思想出现之前，哪些软件是如何开发出来的呢)。做个不恰当的比喻：这就跟筷子更适合吃中餐，刀叉适合吃西餐一样。个人觉得应该是利用合适的设计思想去做合适的事情。总之，不论是OOP还是FP，最终关注的还是数据和操作数据的方法。在这个角度来看，我们是不是更应该关注如何去进行操作抽象和方法抽象。
最后推荐一本书：Structure and Interpretation of Compu...
首先你要明白设计模式虽然说好听是前人的经验总结,其实说简单就是一些常见问题的 "处理模版", 遇到类似问题照着套, 为什么这种常见问题需要程序员人肉来写出模版解决呢? 因为语言的描述能力不足以直接解决这些常见问题! 所以语言越强大,越不需要设计模式(这方面可以拿语法上进化最快的语言C#去看,是不是每个版本都枪毙掉了一些模式,当然因为完美语言不存在,所以设计模式总有存活空间)
如果你说的设计模式是狭义的设计模式(GOF的23种经典设计模式),处理的场景都不是业务逻辑,而是代码里类和类的关系,方法和方法的关系.在FP里,问题根本就不存在,哪里还需要他们???
如果你说的设计模式是广义的设计模式(一切的代码模版),FP也有FP的设计模式,不过对Clojure这类Lisp方言来说,总能定义一个宏把这件事处理了,所以实际上并不需要关心这个问题.
设计模式不就是为了解决OOP的不足所以才会存在的么？
FP就很少存在这些问题。或者说其实也有设计模式，但是不叫这个名字。
可以这么理解，你都用FP了，干嘛还要去看设计模式。