In Functional Programming, the good rule of thumb for composition is to create a function for each operation and compose them together to achieve the desired functionality.
In contrast, in Object-oriented Programming, should each method be self-contained with the use of less helper methods or same as Functional Programming? What is a good practice?
Whether OOP or FP, a function should do one thing.
The good rule of thumb, no matter the paradigm is OOP or FP, is that a function should do one thing.
It does not mean that a function should not internally compose with others.
If helpers method contribute to participate to achieve the sole function/method responsibility, that's pretty fine to use them.
Related
I grew up being taught java, and I've started to learn a lot of PHP over the last few years using popular open-source CMSs. I really love the natural-feeling of OOP, but I've more recently discovered the concept of functional programming, which appears to be a difficult but elegant way of doing things.
In rtperson's great answer to the question "What is functional, declarative and imperative programming? [closed]", he says that "Then there's Object-oriented programming, which is really just a new way to organize data in an imperative program."
I think I understand what he means by that, but is it strictly true? Can OOP co-exist with functional programming?
Yes, there is a term of "object functional programming".
Basically in those languages a function is a "first class citizen" - an object.
I guess most agree it is not so easy to get there just because you have to know about all concepts - functional, OO and imperative.
Examples for such languages are:
Scala (I like it very much)
Boost::function , Boost::bind in C++
.NET F#
javascript (aka ECMAScript)
Yes it's compatible. You can program in a functional way in any language. An example would be Java String which is immutable and returns a new object if you do altering methods such as change case etc.
If you think about it o.something(y) is just osomething(o, y) and if you don't mutate o or do other side effects not related to OO it's functional.
Yes. There is something called a 'functional object', which is basically an object where the mutator methods, instead of changing the state of the object, return a new object with modified state. Clean combines that idea with uniqueness types to keep the modified states single-threaded, which allows the compiler to implement methods by modifying the storage for the object behind the scenes.
Furthermore, there's nothing about mutable state that makes it 'not purely functional'; what's impure is when ordinary expression evaluation mutates state that's visible to the program. So you can combine OO and purely functional programming by making your object's methods return actions in the IO monad (or any other stateful monad) that mutate a common set of underlying state (not available to the rest of the program).
What if I make member variables as const as possible and treat frequently changing data as input argument to the interface method.
So instead of data owning methods that operates on itself, methods owns parameters(const members) and operates on data.
Is this kind of style functional or functional-style, or just call it "stateless OOP"?
Is there any reason to encourage or discourage it?
I wouldn't call it functional, as functional tends to imply that your program is made of composable functions (pure functions ideally). However, the "tenets" of functional programming seem to be there- immutability, referential transparency. The only thing you are (potentially) lacking is functions as first class objects. To truly be considered functional programming you really need to have functions that are treated as first class objects- they can be assigned, passed as arguments, and returned from other functions. So I think this would be considered OOP with functional elements.
Someone who is more well-versed in programming language design feel free to modify or refute this answer!
What makes everyone went from sequential languages to object languages ?
According to Wikipedia the features of object oriented programming are data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. For me data abstraction, encapsulation, messaging, modularity also exist in sequential languages. Only the polymorphism, and inheritance are specific to object oriented programming. Is this correct ?
Many non-OOP languages can certainly build those features. Just looking from a C vs. C++ area, you can provide encapsulation in C by using opaque pointers, with a suite of functions that take/return these opaque objects, and an internal set of functions that are all file-static. You can even do polymorphism and inheritance with function pointers and encapsulated objects.
Then again, we could also all still be programming in assembly or machine language. The reason to bring any feature into a language is to make it easier to use that feature.
Again, looking at C vs. C++, dealing with opaque pointers and the like is annoying, repetitive, and semi-difficult. With C++, you can achieve the same effect with much less code. It's obvious to everyone what is going on. It's a lot more difficult to break (though not impossible). Plus, you make it easy to break encapsulation if you need, since you can define language constructs like friend that provide exceptions where necessary.
And then there are those things that are really hard to implement without direct language support. Operator overloading is impossible of course, but function overloading is really, really hard to do without language support.
Most important of all, if it's in the language, then everyone does it the same way. There are multiple ways of implementing inheritance and polymorphism in C. All of them are incompatible with one another. And while C++ users could do any of those methods, they opt to use the actual language feature 99.9% of the time. This means it's much easier to read someone else's code and know what's going on. You don't have to guess what is opaque and what isn't. You don't have to guess at what is derived from what. You know it, since everyone does it the same way.
In any case, most of the OOP-lite language (C++, Java, C#) can be used more or less like a procedural one if you want. You just ignore the objects. So in many ways, they get the best of both worlds.
The advantage can be summarized this way:
OOP can represent the real world more directly and precisely than previous paradigms, so the program becomes simpler and easier to understand.
And about this:
For me data abstraction, encapsulation, messaging, modularity also exist in sequential languages. Only the polymorphism, and inheritance are specific to object oriented programming.
Most human-readable language can provide data abstraction, encapsulation, messaging and modularity (otherwise they would be machine-languages), but OOP supports better these concepts. For example, to set text of a widget in C, you would do something like this:
HANDLE myEditBox = CreateEditBox(hParent, ...);
SetText(myEditBox, "Hello!");
Notice you have a handle to an object, not an actual object. Now in C++ (OOP) you can make this:
EditBox myEditBox(...);
myEditBox.SetText("Hello!");
The difference is subtle, but important. The C style SetText(handle, "Hello!") does not make any distinction between the handle and other parameters. You don't even know that there's a message to the object. Now the C++ style object.SetText("Hello!") it's like telling explicitly: Hey, object, set your text to "Hello!". Here, the notion of message and receiver (the object) are explicit.
C++ can also destroy objects automatically if they are not declared as pointers, which eliminates calls such as DestroyObject(myEditBox).
Also without OOP you have very poor encapsulation, because most things are implemented with structures which contains only public members. So you can't hide data from users, which mean somenone might try to change things in an unexpected way, that may cause bugs. This is quite common in large programs.
If you have watched Going Deep shows of the Channel9 lately, one very frequently mentioned topic is mathematical duality in programming. TomasP has a good blog post about duality in object oriented programming.
This has been since Microsoft Research found that the observer design pattern is actually a mathematical dual of the iterator pattern. Since then they have used the duality concept in various ways.
My question is:
What mathematical dualities are there in programming?
Object oriented programming is a good start. The major GoF design patterns are: Decorator, State, Iterator, Facade, Strategy, Proxy, Factory Method, Adapter, Observer, Template Method, Composite, Singleton, Abstract Factory and Command. Here is a good object-graph-poster.
I'd say the primary duality in programming is the code-data duality, most clearly exposed in Lisp, but also clear in most contemporary languages which provide introspection functionality.
Not sure if it is entirely what you were looking for, as it's more FP than OO, but there is of course the Curry-Howard Correspondance (a.k.a. Curry-Howard Isomorphism) that "equates" programs with proofs and types with formulae.
You could argue that the duality of observer/iterator is (sort of, work with me here :-) ) a manifestation of the more general OO paradigms of inheritence and the alternate paradigm of delegation and aggregation. In the former, more specialized objects use base functionality (point up) to inherit general capabilities and in the latter, more generalized objects use delegation to access more specialized functionality (point down/out) - there is much academic discussion about the fact that oo designs can be expressed in either form, and since the variance between forms is (reasonably) rigourous and defined, I'd say it could be classified as a dual
See Treaty of Orlando 2 for more info
I think of objects and closures/anonymous functions as duals.
An object is a bunch of data, with a set of routines that are "attached" to it (i.e. its methods).
A closure, in the functional-programming sense of the word, is a (callable) reference to a function, with a set of data attached (in the form of its bound free variables).
I've lately been thinking a lot about alternatives to the class-based approach to object-orientation.
One thing which bugs me in today's languages is that we often use static classes / singletons to design single (global) objects because there isn't any other way to do it, so in my opinion it's rather a hack than a feature.
Another thing is that Java for instance allows the programmer to have enums with additional data (global state) and functionality which make them kind of object in my eyes, too.
Anyway, what I'd like to know is whether you have any ideas for a different approach to object-orientation in a compiled and efficient language (therefore, creating objects by prototyping is probably not a good idea) or, if you don't have any, whether there're things in the classic OO approach which bug you a lot, too.
[EDIT]:
Just to make things clear. As indicated above I already know prototype-based programming.
Check out prototype-based programming.
Take a look at the Actor Model. It's something like classes except for being asynchronous. If each actor is a Finite-State-Machine, you would have a potentially powerful system.
Erlang uses something like that, I'm told... at least similar. The point with the actor model is that it doesn't need to be implemented purely, and so does not need to be part of Erlang.
I started a small language that used that model once a few years ago. I might try it again sometime.
Now that my flame retardent suit is safely secured, I can say it: I dislike OOP.
The central problem I have with it is that it tries to come up with a single taxonomy in which every unit of functionality truly belongs.
There are a couple of problems with this. First, producing a good taxonmy is hard. People suck at creating them. Secondly, I am not convinced that you can actually structure a sensible, maintainable, hierarchy that will withstand change in a project containing a lot of entities; the whole practice of refactoring is basically acknowledging the difficulty of creating large, all incompassing taxanomies.
Actually, I think that OOP is over-engineered. Everything you can do with OOP can be done with higher-order functions (HOFs). HOFs are much more elegant, much more flexible solution to the same problems that OOP tries to address.
So if you're asking of another way to do OOP style stuff, HOFs are probably the closest alternative technology that has a similiar level of flexibility.
I think you are having trouble defining the "classical OO" approach. Is the signal method in Objective-C classical or the static method in standard C++?
In functional languages, it's easy enough to have non-object functions that, in a sense, act like objects because they return functions whose implementations are opaque. For example, the following code in Scheme
(define (create-ball color)
(lambda (attribute-name)
(if (equal? attribute-name "color")
color
"method-not-supported"))))
will output a function which isn't officially an "object" but it can act like one since it stores state, but you're not very clear about what exactly is wrong with the object-oriented paradigms you have been exposed to.
take a deep look at javascript which has the prototype based model or check out lua which has a some strange way to implement object orientation
Take a look at CLOS, which is basically function/method based.
Google's Go language takes a decidedly different approach to object orientation, maybe worth a look.