Is Object Oriented stuff really that important? [closed]

Question

For years, I have been doing Algorithmic stuff, writing scalable data structures for internet search, for example Randomized Binary Search Trees for Auto Recommendation, BitMaps, Wisdom of Crowd based Algorithms using Graphs, writing some interesting Machine Learning Algorithms like Clustering, Anomaly Detection, working on Information Retrieval stuff and so on

There is a common thing in the things that I have mentioned above. All the above stuff;each if coded in a language like C++ requires handful of classes. I mean they are interesting problems but they are not complex in terms of heavily loaded Object Oriented stuff. I have never used Inheritance, virtual stuff etc. Though I have heavily used Generic Programming, Templates and so on.

I love C++ (- Bulky OO stuff, As I like what Joe Armstrong's, creator of Erlang says, In OO World if you ask for a banana you get a big jungle alongwith gorilla holding the banana). I enjoy coding in other languages like Java, Python too.

Now my question is since I am enjoying the kind of projects/Algorithms I am working on do I need to really learn OO stuff, will I be a better coder/designer just by using the stuff like Inheritance, Dynamic Polymorphism (virtuals)? OR can I move to the world of Functional Programming (I have not done it till now) which attracts me more as I can just focus on tasks/algorithms and not let Kingdom Of Noun based OO stuff, has-a, is-a rule me?

In short will/can OO stuff help me at all for the kind of projects/Algorithms that I have mentioned above?

EDIT:

One extremely interesting link to add here:

http://steve-yegge.blogspot.in/2006/03/execution-in-kingdom-of-nouns.html

Answer 1

Object oriented programming is really good at hiding your complex fancypants mathy stuff behind easy to understand words and making it easier for the lessers among you to actually use the things you've written. It doesn't replace functional programming ... it just gives you a really easy way to switch out implementations or add behavior.

In your Randomized Binary Search Trees example above, what if you were given the requirement that on April Fools Day, the Randomizer was replaced with an order-by-distance-from-three-stooges. It's really handy to create StoogeBinaryTree : RandomBinaryTree and override the protected int GetSortOrder (Tree a, Tree b) method, so on April 2nd, you can switch implementation back to the RandomBinaryTree without having to have changed any of that code.

In one simple example, I've shown both adding tiny sliver of behavior and switching implementation...

Answer 2

If you are going to do FP still with languages like Haskell and Erlang that do it well, there is no need to drink the OOP cool-aid. FP Is very powerful and can do a lot even in the real world

That being said, learning an OOP language would not be a bad thing. Understanding multiple ways to program and several methodologies will work in your favor. Plus if you move from Haskell or Erlang to Java you can wonder how in the world anyone can work without a REPL and lambdas.

Answer 3

It seems like you have only been focused on solving a single problem at a time, i.e. writing algorithms. But consider how you'd write a GUI application, for instance, or some other huge application which possible requires you to use a lot of your algorithm. In that case, knowing OO will be essential, since it'll help you simplify your code to make it more readable and easier for other developers to use, e.g. by creating a library that could be a loaded as an object.

One of the most important design patterns in Object Oriented Programming is the Strategy Pattern, which in the above scenario also will help you greatly. Consider an example where the user would present you with input on which you'd allow the user to perform an algorithm. This could easily be a messy if/else or switch/case construction. By creating a common interface for your algorithm and using Strategy Pattern, your code would be much more flexible, readable, easier to extend, and thus easier to maintain.

Answer 4

Object-oriented approach became successful because of one crucial aspect: it lets you tackle systems of significant essential complexity without introducing too much accidental complexity. This can be almost ignored when you work on homegrown systems, but becomes very important when you build large-scale systems.

The key elements of the object-oriented approach can be explained to a programmer with extensive exposure to procedural programming in a matter of a few days, which helped the technique gain popularity quickly (this is not to say that you can become an expert in a couple of days: it's similar to learning chess - you can learn how to move your pieces in under ten minutes, but it takes years to master the game).

Functional programming techniques are gaining more importance with the introduction of language support for them into mainstream languages (lambdas and anonymous delegates of C#, lambdas of C++, and even anonymous classes of Java, to a certain degree). It is very helpful to understand these techniques, but they are designed to address more localized problems on the tactical scale. Object-oriented techniques, on the other hand, remain relevant on the strategic scale, especially in the context of larger teams.

Answer 5

Do functional programming, it will be a very good experience for you, even if you decide not to continue. As you can read out of some of the answers here, many people don't even know what it is.

Functional languages concepts, eg lazy evaluation and referential transparancy, are a very very good thing to learn. Especially if you like recursion.

for example:

lenth :: [a] -> Integer
length (x:xs) = 1+length(xs)
length [] = 0

is a very simple haskell function that recurses through a list and calculates the lenght. If you are interested in numbers bigger than long long and want to use infinite Lists and other fancy stuff, give functional programming a try.

Answer 6

As others have said, object-orientation is the dominant paradigm in industry. You've said that you've worked mostly with programs that can be addressed by a handful of classes, but in an industrial application there are hundreds or thousands of use-cases that need to be addressed and object-orientation has proved a very reliable and broadly comprehensible way to structure such large codebases.

You talk about functional programming, which is a solid contender for The Next Big Paradigm, but FP is not yet familiar in industry. Especially as you are a C++ programmer, you should know that industry can be conservative and the C/C++ world, with its emphasis on performance, is a place where the imperative nature of hardware is seen as a very real consideration. In general, embedded systems programmers are extremely skeptical of FP, in my experience.

Even if FP does become a more dominant paradigm in industry, it is certainly the case that it will succeed in the form of object-functional hybrid languages such as F# and Scala and not in the form of "pure" FP languages such as Haskell.

All of which is to say that, yes, object-oriented "stuff" is important to professional codebases and your career.

Answer 7

OO gained traction because it was a big improvement for handling complexity, as before it structured/procedural programming also was.

The benefits of using OO increase as the size of the project increases. For a 1KLOC program, it doesn't matter much which paradigm you use, all of them will work OK. But for a 200KLOC+ program, there's simply no viable competition for OO. That doesn't mean you can't write a 200KLOC program in C, just that you'll have to be a lot more disciplined to avoid ending up with a mess that no one (not even you) can understand. That doesn't mean that OO will prevent such mess, just that it'll make your life easier in order to prevent it.

Functional programming is a paradigm that somewhat deviated from the previous pattern, because it didn't come to help handle even more complexity than OO did, but to address a different sort of problems: parallel programming. That was the first time, also, that a programming paradigm attempted to do so: all the mechanisms that existed before in OO and/or SP/PP were not part of the paradigm, but just OS entities (threads, mutexes, etc.) encapsulated according to the paradigm rules.

In that regard, FP is a lot more natural than the others, but that comes at the cost of reversing the way we usually think about the problems. And due to that, it has a limited capacity to handle the very same complexity at the same scale that OO does.

My guess is that this will limit the adoption of FP in the near future to very specialized systems, in general not much big, or specialized sections of bigger systems. And the rest will still be made using OO. Which of those you plan to develop (or learn about the development) will determine what should be your learning focus, IMO.

Answer 8

Though I have heavily used Generic Programming, Templates and so on.

Arguably, templates are simply a different form of OOP. Virtual functions and explicit inheritance have a specific use case- run-time, binary interchangability. Templates are compile-time interchangability. However, at the most basic level, they offer the same feature- abstraction over any type which offers the correct interface. Over-use of run-time inheritance is a significant code smell, and in this case, I agree with you- it simply isn't needed for much of the time.

template<typename T> void func(T t) { t(5); }
void func(std::function<void(int)> t) { t(5); }

These two snippets are effectively identical, even though one uses templates exclusively and the other uses run-time inheritance and classes as it's implementation. They both abstract over the function you're calling. This is trivially obvious when you substitute T for std::function<void(int)>, for example. The only difference is the time at which that abstraction is made. The template version excels for functions, and std::function is generally better off as member variables. You don't want to have to create a new class every time you want a new callback.

OOP is not particularly well-suited for algorithms. It is more intended for large-scale constructs, breaking down the pieces of the program. If you are writing a specific algorithm operating on specific data then it's unlikely you will need classes.

It's easy, and it's great, to compose algorithms of functions. However, as soon as you get beyond that, then classes emerge as the dominant method.

Answer 9

Yes, it is important, for this single reason: understanding OOP makes you a better programmer. As a rule of thumb: understanding always makes you a better programmer.

It should be noted that neither is-a, nor classes let alone inheritance have anything to do with OOP. What OOP is really about is decoupling through indirection, as formulated by the dependency inversion principle. One can argue that this is also an important aspect of FP. If study both OOP and FP, you will increasingly become aware that they are actually two sides of a continuum. The broader and deeper your understanding of it, the better you will become.

To get an understanding of OOP try Io and maybe Smalltalk and Ruby.

Answer 10

In the development world, languages are tools, programming paradigms are tools, and libraries are tools. The more tools you have, the better able you are to select the right tool for the job. So that would argue for you to learn OO, AOP, and Functional programming - as time permits.

The development world keeps growing larger and larger (in terms of languages, frameworks, etc), so you can't expect to learn everything. However, the goal of all these innovations are to help developers become more productive (speed of development, and reusability), and to make code more maintainable (ease of understanding, ease of extending and modifying).

The best thing you can do is to do targeted, continuous learning, in the hope that something new you just learned helped you complete something better and faster in a way you never expected.

Answer 11

I have been reading the Steve Jobs book and in there is a story about how Steve saw SmallTalk at the Xerox PARC labs. That was one of the earliest OO languages. Without OO it would have been horrendous to develop something like a Graphical User Interface (GUI). With all the asynchronous input and being able to jump from task to task while working with one "Object" or another.

So while you can do a lot with a functional language and it definitely has it's use cases. When you start dealing with more complex systems that interact more with real world problems you find OO to be a superior design.