Stateless Object Oriented Programming vs. Functional Programming?
One of the prime reasons for the increasing shift in attention towards functional programming these days is the rise of multithreading/processing and the advantages of FP's focus on side-effect free, stateless computation in making scalability effortless.
Certainly, though, in Object Oriented programming, we could also shift to a stateless paradigm, where all objects never get to mutate state. This can be a convention, or perhaps even implicitly supported by the language. For example, in languages that enforce uniform access between object fields and methods, simply not allowing setter methods would accomplish this.
My question is, then, since OO can utilize statelessness and nothing about objects mandates statefulness, is OOP effectively a superset of FP? Are there any additional advantages / features of FP that makes multithreading more practical than in OOP?
It's a question of degree.
The advantages to using a functional language for functional programming are the carrot and the stick. The carrot is that functional languages have functional syntax and semantics and come with functional libraries. The stick is that functional languages can force you to adhere to certain standards. If you do FP in a non-FP language, you get neither of these. You will necessarily be fighting against a state-friendly standard library and have to police yourself to ensure you don't create state.
The analogy to doing OO in C is a good one. There are times when your constraints are such that C is the right choice, and an OO structure is also the right choice. GTK is a good example of that. It's very hard to write a UI toolkit without OOP. However, this means you're taking on work that would normally be done by a compiler. Some things that are easy in one language become difficult or impossible in a language without syntactic and semantic support. I've never seen a C project that emulated multiple inheritance, for example. It's just too much manual labor.
If you were to adopt a functional style in your OO code for the sake of parallelism, it's quite possible you'd achieve the benefits you're after without a lot of pain. But you'll still be missing out on compile-time guarantees that your code is pure, in-language support for FP and the impressive optimizations that FP compilers are capable of these days. It's a trade-off, so this is a decision that must be made on a case-by-case basis, and it's one only you can make.
As for whether or not OOP is a superset of FP, I don't even think the concept is meaningful. In terms of expressing programs they're both completely capable. You can implement an OO language in an FP language and vice versa. Sometimes one is closer to the problem domain, sometimes the other. Regardless, I think your real question is whether or not one must like FP, and the answer to that is, no; use what you like.
I think you should also consider checking out the Actor model, because it is more appropriately OO and not state-unfriendly (just shared state-unfriendly), while still yielding scalability/parallelism benefits.
I had this same understanding at one point and was "Corrected". Not being a functional person I don't get it, but apparently there are some tools in functional languages that adapt themselves better to that style of programming.
I think it's like a C programmer saying that since C methods can be combined into a struct and replaced doesn't that make C a superset of OO? In fact, this is how C++ was initially implemented, but it does not make C an OO language.
FP is more about the way you solve problems, than language you use. So no OOP is not superset of FP. Some constructs in FP (mapReduce, ...) can be implicitly converted to multithreaded application. But nothing prevents you from using them in OOP. It's all about mindset.
链接地址: http://www.djcxy.com/p/80810.html下一篇: 无状态面向对象编程与功能编程？