在Scala中坚持只使用函数式编程范式的有效性
在Scala中坚持只使用函数式编程范式的有效性
我最近购买了《Programming Scala》并一直在阅读它，这种语言完全超出了我的预期！具体来说，它似乎实现了我所了解的除Lisp宏和Haskell类型级别的副作用隔离以外的所有编程语言思想。
坦白地说，它让我有点不知所措。虽然我想对于我而言拥有这么多工具还是不错的，但我真的只是在寻找一种在JVM上强类型的函数式语言。我想我可以用Scala这样做，但我想如果我与任何库的交互或查看任何其他人的代码，我将遇到大量这些高级OOP内容-特征和\"对象层次线性化\"，所有这些抽象和覆盖业务，单例，包和伴随对象，隐式转换...更不用提各种语法快捷方式和糖果。
人们经常抱怨那些试图将一种语言的风格塞入另一种语言的程序员，有很多非常好的理由。但并不是所有语言都像Scala一样多范式，所以也许它的社区有不同的观点？例如，在F＃中，似乎可以在编程风格和使用多少OOP方面有些灵活性。但只是从阅读中，我不确定这是否也适用于Scala的好哲学。
有更有经验的Scala程序员可以帮助我吗？编辑以确保清晰：基本上，我是否可以安全地使用Scala的FP功能而不必担心其高级OOP方面？
对于问题表述混乱我很抱歉！
让我对Kevin的答案添加一些评论。
Traits主要用作抽象（宽泛地说，就像Haskell类型类定义抽象一样）和Mixin。所以，我的代码可能会使用Map trait，但实际上它正在使用像HashMap这样的类型的实例。相反地，如果我希望我的"Service"类型具有日志功能，我可能会混入可重用的Logging trait。
幸运的是，你很少需要考虑线性化算法超出简单的情况，例如，我可以混入一个截取（包装）方法调用以记录被调用的方法的事实的trait。该算法需要处理更复杂的线性化情况（像我们在书中展示的例子一样），但实际上，这种复杂的类型是一个糟糕的设计，依我之见。
单例，包括特殊的子集伴生对象，旨在使一切都成为对象，但是您也可以将它们视为包装函数和可能的某些状态的命名空间。
隐式转换非常有用，但有点"神奇"。您可能会发现对于如何使用它们来模拟Haskell类型类很有用。这里是Debasish Ghosh的一篇很好的帖子：http://debasishg.blogspot.com/2010/06/scala-implicits-type-classes-here-i.html
你看到的是Scala最重要的特点，它是在JVM上的强类型函数式语言。
Scala不仅仅是一个函数式语言。它最初是作为一个函数式语言启动的（Funnel：http://lamp.epfl.ch/funnel/），但后来被扩展为一个面向对象的语言，其明确目标是使其能够与Java类强交互。
抽象化、覆写和程序包等都是这种互操作性的实例。
剩下的可能被认为不是新功能，而只是从Java中删除的限制。一个一个来看：
特征和对象层次线性化
去除了Java接口只能包含抽象方法的限制。线性化是Scala解决钻石继承问题的方法，否则会导致该问题。
单例
Java静态方法是其C++语法遗产的副产物，而C++又是为了更好地支持与C的过程式风格互操作而添加它们的。静态方法非常不面向对象（请参见此问题：为什么单例对象更面向对象？）
伴随对象
允许使用单例替代静态方法，具有特权访问权限。
隐式转换
Java已经可以做到这一点，但仅限于将对象和基元隐式转换为字符串，例如表达式"" + 3。Scala仅是扩展了这个思路，允许程序员将其用于其他转换。