Take the 2-minute tour ×

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?


migration rejected from stackoverflow.com Mar 22 at 10:57


closed as too broad by gnat, Thomas Owens Mar 22 at 10:57


If OOD does not fit your problem domain - you must not use it. And an object-oriented way of thinking actually fits only a tiny proportion of practical problem domains. Do not listen to all that OO BS, it is nothing more than a system of religious beliefs, not a science or technology. –  SK-logic Jun 4 '11 at 10:33
In general, the larger a system is, the more these techniques are necessary. It doesn't sound like you're involved in writing terribly large systems? –  red-dirt Jun 4 '11 at 10:52
I think of C++ classes are an evolution of parameter blocks. A fairly common pattern I use is what I call a "tool class" - it may have "settings" members and methods to help set them up for common cases, but it's really just a convenience for (repeated) calls to a function (or a few functions) that share those settings. In terms of school OOP theory, the shape no longer draws itself - but the shape drawing tool may hold some parameter-block-style settings. –  Steve314 Jun 4 '11 at 11:00
@el fuser, OOP is not necessary at all for large systems. In most cases it is in fact quite counterproductive. –  SK-logic Jun 4 '11 at 12:54
The reason C# and Java programmers put everything into a class is because the language forces them to. For some situations this is useful, but for the sort of code you are writing it is probably just useless overhead. If you don't need it don't do it - and avoid languages that force you to do it whether you need it or not. –  Dave Kirby Jun 4 '11 at 16:57
show 8 more comments

16 Answers

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.

+1 for the first line. –  Billy ONeal Jun 3 '11 at 23:53
OOP might not be the same as wrapping everything in a class but it sure feels that way when you're writing enterprise applications. –  davidk01 Jun 4 '11 at 1:00
enterprisey != oop –  Brendan Long Jun 4 '11 at 8:09
The "enterprisey" software I've seen has been the extreme poster child of the "Java cargo cult" programming I mentioned above. It has nothing to do with OOP, but it hides everything beneath 4 layers of abstraction, everything is behind an interface that never serves any actual purpose, and your class hierarchy is deeper than the Mariana Trench. It's based on ritual, not design-. –  jalf Jun 4 '11 at 8:16
+1 for "But make sure you're actually looking at OOP, and not at Java's brainwashed OOP bastardization." –  otibom Jun 4 '11 at 12:11
show 7 more comments

from your description, no


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.1

1Drop me a line, sounds like a good case study for my book

You beat me to this one. After ten years, you've probably seen everything you have to handle .. something should be doing that for you. Heck, even after ten months. –  Tim Post Jun 4 '11 at 2:59
@Steve314 that would be absurd. –  Steven A. Lowe Jun 4 '11 at 22:12
show 1 more comment

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.)

+1 for the link about eating corn. I hadn't seen that before, and it's eerily accurate in my case! –  Daniel Pryden Jun 4 '11 at 22:39
add comment

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....

add comment

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.

add comment

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.

Yes and no. If done right OOP can be very useful for a data layer. For a program that accesses the database in a similar way, defining all the data access logic in a base class and then having less experienced developers implement the sub classes which handle the business logic can be beneficial. At one place I worked this worked out quite well for them. –  Cervo Jun 4 '11 at 23:48
add comment

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.

add comment

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.

add comment

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.

add comment

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.

add comment

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.

show 1 more comment

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.

add comment

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.

add comment

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.

add comment

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).

add comment

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

add comment
