Do I really need oop for my kind of job? After 10 years I think I don't

Question

After 10 years of writing something like business logic for my company I realized that for 95% of my code I just don't need any special OO techniques. For years I tried to get better with all that OO stuff. But with every book or article I got more confused and the resulting code was uglier and harder to maintain. And it always felt wrong and much to complicated.

The point is, that my job is very easy from an technical point of view. Read stuff from a database (not really SQL), do some calculations and maybe write something back to the database. Handling errors and transactions correctly is the biggest issue.

I found out, that the easiest way to express myself in c++ for what I have to code is to write plain functions. Maybe handling parameters with structs from time to time. But that's almost it. I wrote some helper classes, that I need on a regular base, but that is not necessary very often.

But in the past I surrounded every little or large peace of code with a class. And that is also what my co-workers from the c# department are doing and telling me all the time.

My question is, what is going wrong with us, that we think, that we can solve every software development problem by throwing just more OO techniques on it?

I needed 10 years to figure out that less is more. I looked through the book written by this guy from Romania who does a lot of magic with templates. And I thought: "Man, this looks so interesting - why are you just not needing it??"

Since this here is for Q&A: How much OO do you need to get your job done? And how often do you think, that you are doing something more complicated that necessary just because you have read about a new cool idea. And what do you do to not get into the overdesigning trap?

Answer 1

OOP != wrapping everything in a class.

(As I recall, the "inventor" of the OOP paradigm said that he feels it is characterized by "message-passing and extreme late-binding of everything" -- not a word about classes)

The whole "everything must be in a class" notion is just Java's cargo-cult programming style. Because someone once used classes in a piece of well-designed software, Java's designers (and Java programmers) tend to think that "we just have to use classes too, then we'll be able to attract any *'well-designedness' that happens to be passing by"

There are some important and useful properties associated with OOP, properties that can make your code easier to understand and maintain. But the ritualistic cargo-cult paradigm that "everything must be in a class, everything must have a base class, every function that can be made virtual must be made virtual, and the only legitimate way to write polymorphic code (or in extreme cases, any control flow at all) is through interfaces and inheritance" is pure rubbish. It's upside down, and it's an attempt at mimicking successful software architectures without understanding what made them successful.

Take what you find useful from the OOP paradigm. But make sure you're actually looking at OOP, and not at Java's brainwashed OOP bastardization.

And then take what you find useful from the FP paradigm. And, for C++ especially, the generic programming paradigm must not be underestimated. Take what you can from that as well.

They're all just tools in your toolbox. Having more tools at your disposal can only ever be a good thing. But you don't have to use any single tool all the time, and it may turn out that some are hardly ever needed. But it doesn't hurt to know about them.

I think it's important to have the right perspective though.

If you look at it as a a simple choice, a linear scale with "OOP" on one end, and "Procedural/C-style" on the other end, then it becomes a battle between extremes, and there's little objective reason why one end should be better than the other.

But it's not that simple. There are half a dozen major paradigms to consider, and you can mix them, tweak them and adapt them. It's not a question of "am I for or against OOP", but "do I want to stand still where I am, or move and spread out and learn and adapt and improve". And then the answer is obvious. Always choose the latter. Don't just write C code for the rest of your life. Study every other paradigm, and see what it brings to the table. it might not turn your coding style upside down, but it may be able to teach you new ways of thinking about the problems you have to solve. It may lead to better ways to write readable, maintainable, efficient and reusable code.

Answer 2

How much OO do you need to get your job done?

This completely depends on your job. If you're writing a one-off routine, and it's just going to read in data, process it, and write the data back out, then designing a class hierarchy to help may not be beneficial, at least not for that specific job.

However, if you're doing this all of the time, over 10 years, chances are you've probably had to write and change and tweak a lot of very similar or the same code multiple times.

At this point, if you'd been writing a clean, object oriented library of reusable tools, when you need to write these jobs, you'd just have to write the code that stitches them together. For example, the code to read from the DB and write to the DB could probably be encapsulated very nicely, and turned into far less code each time you do one of these little jobs. Chances are some of the "plain functions" you've written handle related functionality and could benefit from sharing their own data and managing it internally.

My question is, what is going wrong with us, that we think, that we can solve every software development problem by throwing just more OO techniques on it?

Most of us don't - but we've found that OO does tend to help us write code that's easier to maintain, test, and reuse... There are other paradigms than OO, as well, which are incredibly useful - often more useful than OO, such as generic programming. Learning to apply these techniques appropriately really is beneficial over time.

Answer 3

from your description, no

Except...

Handling errors and transactions correctly is the biggest issue.

I would expect that this issue would - after 10 years - have been solved by a framework, library, macro, or some kind of repeatable structure. Sounds like a good candidate for OOP to me.

The rest - can't tell without seeing the code.¹

¹_{Drop me a line, sounds like a good case study for my book}

Answer 4

OO is a programming paradigm. There are lots of programming paradigms. OO has a lot more zealotry around it namely because that's what's taught to new programmers as their first language in most cases.

That does not mean that OO is the best approach to solve your particular problem. C++ supports multiple paradigms, and you should choose the best one available on the language to solve your problem. The STL is a wonderful example of this -- where it makes sense to use OO, it is used (e.g. the containers), but where it does not, OO is not used (e.g. the algorithms). sort is not an object, therefore it shouldn't be represented as one. Alexander Stepanov (the original STL's inventor) criticizes OO quite a bit, and his library shows that OO is not always the best way to accomplish things quite well.

The most important thing here is to use the best tool for the job as the job dictates. Don't follow one particular convention or style just because someone said so. If they say you're taking the wrong approach, prove them wrong -- show in code why your solution is clearer than theirs. Code can be incredibly motivating for breaking up those who have hammer-nail syndrome.

Answer 5

I like the way Python do it. Functions are encapsulated into namespaces instead of objects. Everything is a object. But usually, you don't need to derivate classes to do your job, because interfaces are defined by functionalities.

I think OOP can be a good paradigm, but it doesn't necessarily imply hierarchies of classes. Python is a godd example of that.

Even if you program using functions instead of classes, C++ can be better than C, because it has a more powerful syntax, and because you can use a lot of existing classes, STL for example. I don't think it's bad to use C++ without building complex objects.

Answer 6

Let me guess, you eat corn in spirals. :-)

On a more serious note, as others have said, OO is but one way to encapsulate the design of code. It provides a standard language and vocabulary for abstraction. That language is not the only option, and is not always the best one to use. Also it will appeal differently to different people. For instance generic programming is an alternative, and people who use generic programming in C++ frequently are not big fans of OO.

I would suggest that you find a style that balances comfort+productivity for you with not freaking your co-workers out. For different tasks and organizations, different balances are appropriate. That may result in a certain amount of pointless (from your point of view) OO wrapping of not-really-OO-code.

In the process of finding that balance I would suggest a certain amount of deliberate experimentation, to figure out what a different style will look like. If possible choose throw-away programs to experiment on so that you can throw away that code if it doesn't work out. (Or else experiment at home then only slowly introduce ideas at work.)

Answer 7

I don't think that you "need" OOP for anything. The question is can it make your life easier. The problem is that there are a ton of debates on what OOP is and how to use it.

On a basic level, I think classes in general give you a better namespace. In C it does get a bit tiresome to start naming functions My_Company_My_Module_FunctionA() and objects/namespaces can save some typing. Then you just get a reference to a class c and can just be like c.FunctionA(), c.FunctionB()....

Another note is containers. Often object oriented languages provide more generic libraries for stacks/queues/etc... C++ in particular has templates. So instead of needing to code something with void pointers, or different versions for different datatypes, you can just have one list/stack/etc class. which handles every datatype. In most C programs that I look at, I see multiple implementations of linked lists as opposed to making a single implementation and then recycling that. In C++ you actually get the Standard Template Library which contains many collections (along with algorithms to manipulate them). I would say the STL implementations/algorithms are more likely to be correct than a home grown set, especially if you have multiple implementations of them spread throughout the code.

Also a lot of C programs have if/switch statements all over the program. E.g. you have a program to process different messages and various functions ProcessHeader, ProcessBody, etc. and tons of sub-functions. All over the program you switch (or use if statements) based on message types because different messages have different formats. Now you add a new type...where do you make the change? You need to go through all those functions and review them. If you used OOP and factored the code correctly, you could get by just adding a new message class (which inherits from some generic class with a ProcessHeader/ProcessBody/etc..) that you override. Then all over the place the code does not need an if/switch statement. Instead it can ask the generic object to perform whatever operation and then each message type object can decide how to do it..... In addition to reducing errors and making the changes required for new items in a single place, it also makes it easier to identify where to make changes. When things are scattered it is often hard to find where you need to make a change...

One thing about C++ (not necessarily oop) is exceptions. You mentioned that you need to handle errors. In C error handling is tough. Functions return error values that have to be checked everywhere. Sometimes you even need to consult errno. The good thing about exceptions is that you can bubble them up. Sometimes if a really low level function has an error there isn't much you can do to recover at that level. Maybe you'll need to return/process an error through 4 or 5 functions before getting to a level where you can recover. With exceptions you can just throw an exception and instead of having error checking code in those lower level functions you can catch/handle it at a higher level...

Also the other thing is that it is possible to use OOP in C. You can code with an OOP style (which a lot of the more maintainable C is). It all comes down to encapsulation. After all, if you use structs to hold data, and a bunch of functions to manipulate those structs in your different modules and then only use those functions to access the data....then basically you are coding an "object" in C. If you are externing global variables all over the place, then that is harder to maintain. But for smaller programs it is fine...

In any case, I think you need to explore both OOP and the various approaches to it (design patterns, object thinking (behavior oriented object design), data based thinking, etc.... You may be managing fine in a non object oriented way, but unless you explore the object oriented way, you'll never know if it can simplify your life. One major change between an object oriented program and a non object oriented program is the control. In a procedural program often there are some methods that control a bunch of other methods (either a main loop or a main section of a module) while in an object oriented program often the control is delegated around a lot more (which actually leads to better decomposition in some cases). Still it's all a balance.

In short, I would be surprised if you did not find something useful from either OOP or even just C++ (I'm thinking exceptions would probably benefit you and simplify some code...but again I'm not sure).

On one job I remember that I was having trouble making a web interface. It had all of these individual text boxes along with a bunch of rules about filling them in. Generally I do write things procedurally. But in that case I made an object for the box and the collection of boxes. I charged the object with converting the structure to HTML and from HTML into an array. The collection object told each individual box to handle itself. Overall when done it was much cleaner and easier for me to manage mentally. Still I am not an OOP expert. But the very thing that made the mess of a screen manageable to me (delegating the control to these sub objects) seems to be the main benefit of OOP advertised by a number of sources.

Also there is a lot of bad OOP code out there. There are all sorts of poor inheritance hierarchies (one of the reasons the design patterns book advises favoring composition over inheritance).... Also people throwing in objects for fun and writing mostly procedural code (like I do most of the time). But the real OOP seems to be about letting objects be responsible for themselves. Instead of a method doing a bunch of steps and checking each step to see if it was done, you call objects which do things and they are responsible to do it right or report their failure...

For example you have a data loader. If you had really different file types, you might have a DataLoader object and tell it to LoadFiles. Also if you are always talking to the same database, you may have an object DataBase responsible for connecting to the database, hitting it with queries, returning data, and doing all the error handling. If you always follow a prescribed set of steps, DataLoader might define the steps and even a routine to perform the steps in the right order, and then you might subclass DataLoader to actually perform the steps for each file type.... But overall I don't know.... It really depends on your situation. Also you don't need to go all OOP at once. If you have some piece of code with more defects then the others, you might think of how you might model that as a set of objects and how to break up the responsibility/control....

Answer 8

As a code structuring mechanism I think object-oriented programming is overrated and as far as abstractions go classes are practically useless. After having worked with dynamic languages like ruby and javascript and more static ones like java and c# I can tell you that all I really need to write structured code are first class functions and closures. Everything else is just fluff and usually does more harm than good. The proliferations of design patterns and anti-patterns I think is good evidence of this useless fluff.

Answer 9

Both OO and C++ entice people into solutions that are more complex than necessary. Probably the most notorious example is database access. I still can't believe how many companies develop their own libraries to talk to the database. Since that's a topic even Microsoft can't get right, most in-house teams end up with a horrible experience.

The thing is that it takes a ton of time to write re-usable code. You have to test it better, it's harder to design, and often has to support multiple versions in production. If you have some spare time, watch How To Design A Good API and Why it Matters by Jusha Bloch. He basically lays out the minimum amount of care you have to put into writing a reusable library.

Most businesses are simply unable to produce good enough libraries.

Answer 10

People were writing good and bad software long before OOP became popular. After it became popular people are still writing good and bad software. OOP/OOA/OOD are simply one of many programming paradigms that promised the earth and failed to deliver. I wouldn't reject everything about it, but I think you need to apply it judiciously. That's why I quite like languages such as python that support a range of paradigms. If OOP doesn't seem like a good fit for your problem I wouldn't use it.

Most of the programming work I've done has been programming business applications and I've seen all sorts of languages / frameworks come and go. And believe me, I think the trend is towards more complexity that doesn't necessarily produce better software. Indeed some of the more recent popular languages I think are terrible. Personally I think if you are writing business applications with a database I think it is preferable to just include the business logic in the database too in the form of stored procedures / functions / packages. In my opinion N-tier applications are a failure.

Unfortunately I agree some of the Java stuff I have seen is among the worst, EJBs anyone?

The most important thing when developing software is to understand the problem domain, to have an appropriate design, and to produce clean and readable code.

Answer 11

It completly depends on what you are trying to implement and in what situation. Advantage of OOP is - maintainability. I agree that we can complete our task without it, but at the same time, we will face the heat when we are asked to maintain the same.

Developing is not the only thing we do with a software product, we need to maintain it as well. To manage this in a cost effective and qualitative manner we need to develop the product in a manitainable way.

Check http://techbookshelf.blogspot.in/2012/06/does-object-oriented-approach-improve.html for details.

Answer 12

Personally I see huge gains in writing business logic after switching from Java (OOP) to Clojure (functional Lisp).

IMO the reason is not only functional vs OO programming but also REPL (read-eval-print loop) and extremely concise syntax.

Answer 13

OOP is about identifying shared interfaces. If you get the gnack for finding shared interfaces it can make it easier to extend the app in the future. Easier for two reasons:

1. you don't have to update a bunch of "if-this-type-then" all throughout the code when you want to support a new thing.
2. there is a clearly defined contract for extending the app. In theory you only have to test the fulfillment of the contract without any regression tests on other parts of the app (in practice you need to regression test anyway).

Here's a concrete example. You have a comparison program. Compares the structure of databases. Your program starts out working for Oracle only. Then you add support for SQL Server, MySQl, etc. Each time you want to support a new database, you merely implement an interface a it magically plugs in to your program. you can test the hell out of the implemented methods and if it passes, you are there. This is the nirvana of OOP.

OOP is not about putting everything in a class. It's about identifying interfaces that are good candidates for extending the app.

Answer 14

This sounds like a problem with being set in one's ways. My question is what was the last language you took an appreciation in and learned? Have you done anything with any of the following: Python,Ruby, Go, F#, Node.js or any of a myriad of other languages? If the answer is no, then obviously you will not see the value in using a different programming paradigm for a problem. If the language you are using is an OO language, use OO, and the same is true of any other language that was built to a specific paradigm. The reason why OO is popular is that people think in terms of objects, that is why aspect oriented programming is not as popular as some would hope.

Answer 15

I've said it before and I'll say it again - Inheritance, the cornerstone of OOP, is the last tool you should reach for, not the first. That doesn't mean you should not use it, only that you should know why you are using it. And it doesn't mean that you should not use classes (without inheritance) as a convenient way of parcelling up units of functionality - but doing that is not OOP.

Answer 16

This is the question I have as well.

And what I've arrived to, is that OOP has it's place, but it has to be natural. Sometimes data access layer is perfect candidate for isolated class, or a state machine. You lock the private members out, you protect member functions, you encapsulate the logic, export some narrow interface to the application and it's just perfect.

Or sometimes you can create a templated base class for window handling that does all the common functionality while you leave the custom functionality to derived classes. And it just works, everything is clean and nothing gets in your way.

But abuse OOP it becomes super ugly, super fast. Unnecessary pure virtual classes. Spaghetti code all over the place, all the gotchas that surface because of these design decisions. Increased complexity during debugging. Nightmare in multithreaded scenarios, with virtual callbacks all over the place, etc.

So I think that OOP is very cool, but you have to know where to use it. And if you can get away with compile time polymorphism (templates), don't make a mess with run-time polymorphism (pure virtual classes etc.).

And interviews which jump to OOP gotchas, and how you OOP an abstract problem are wrong, IMHO. If you use C++, write simple, maintainable code in the first place. If you have to explain why "here be dragons" something is very wrong already.

Answer 17

I agree, not all jobs need OOP.

As to why we think solving using more OOP techniques, I think, it is a mixture of starting to follow the leader (OO paradigms) venturing unknown waters trusting the leader’s intellect (usage of OOP techniques) and applying the same on every opportunity and use the leader’s corrected vision (more advanced techniques - patterns) while there is a rush to implement a real life business solution which ends up being hard to manage.

I think, Functional languages seem to align more naturally with most of the problems I deal with (although it takes time to start looking at problems differently).

Answer 18

Watch this inspirational and insightful talk on the subject by Rich Hickey, the creator of Clojure:

In his keynote at JVM Languages Summit 2009, Rich Hickey advocated for the reexamination of basic principles like state, identity, value, time, types, genericity, complexity, as they are used by OOP today, to be able to create the new constructs and languages to deal with the massive parallelism and concurrency of the future.

Answer 19

OOP is essentially a way for management to make managing programing projects easier. Without OO design principles throwing more than about 5 programmers at a problem turns the project into a slow crawl. If you never have a need for large teams to work on the same project together there isn't much that OOP can offer apart from a small chance of code reuse or the ability to take advantage of polymorphism though in practice these benfits are much lesser than their theoretical usefulness