Paraphrasing a recent question: https://softwareengineering.stackexchange.com/questions/52608/what-is-object-oriented-programming-ill-suited-for

I would like to ask the opposite question:

What kind of programs cannot be written unless you use OOP?
What kind of programs are not recommended to be written using non-OOP techniques?
What kind of programs need OOP in order to even be written? What kind of programs would be too hard to write without OOP ?

The answer to this question can help sell the idea of OOP to project leaders that have no special interest in code quality. At least they could buy the idea if one shows them the kind of things that are not even possible unless you use OOP.

  • 14
    Every program could be written in assembly with no design paradigm applied whatsoever if desired. Don't believe the idea that something isn't possible without one thing or another, it's just a matter of what tools work well for a given problem, the wrong tools will always work too, unfortunately. – Jimmy Hoffa Oct 29 '12 at 16:21
  • 3
  • 2
    What manager is out there saying "You're not allowed to use OOP?" – Robert Harvey Oct 29 '12 at 16:37
  • 3
    "Every program could be written in assembly with no design paradigm applied whatsoever if desired.": You could use a similar reasoning and, to someone who's asked you why when they should use a car, say that they could go anywhere on foot. – Giorgio Oct 29 '12 at 17:35
  • 2
    @RobertHarvey, in long term - yes, since such a person will work faster, producing cleaner and more maintainable code, will need much less time debugging and testing, and therefore an amortised cost will be significantly less than a cost of a whole team of OOP coders. – SK-logic Oct 29 '12 at 18:38

Technically, there are no problems in the field of computer science that cannot be solved without OOP. Object-oriented principles generally define the layout and architecture of source code; once the code is compiled into assembly language for consumption by the CPU, most of the patterns of OOP disappear.

However, since so many modern languages are designed to be object-oriented, a program written in such a language that doesn't make use of the built-in support for OOP may actually require more effort than simply building the program using the tools available. Managed-memory environments like the Java/Dalvik VM and .NET CLR typically use languages designed from the ground up to be O-O, and there's no way to escape it; at the very least, you need the object that contains the main() method (and any subroutines it calls).

As far as programs that require object-oriented architecture, I think the ones that come closest are event-driven GUI programs. The frameworks given by the GUI SDKs are object-oriented, and while I'm sure you can write a CLR program composed entirely of hooks into unmanaged Windows API code to create and display windows and react to the user's input in those windows, the overarching question I would pose faced with any such attempt is, "WHY!?", when the framework presents you with the objects representing all the GUI controls, each one handling the basics and most of the advanced usage scenarios in a neat, tidy package?

That's the strength of object-oriented programming; the "black-box concept". You don't have to care how anything is actually done; you simply care that it is done when you want it to. Why hook into a dozen Windows API functions and make hundreds of calls to display a window on the screen, when you can just call Form.Show()?

As far as convincing management that OOP is a good thing, the argument is all about time. OOP was designed to save the developer's time by increasing code reuse. General-purpose code-objects, which already exist so you don't have to rewrite them, are derived and combined into the specific solution to your particular programming problem. Those objects are also modular (if you follow the Gang of Four design patterns which encourage adherence to design principles like GRASP or SOLID), meaning if a piece of software has a problem (doesn't have to be a bug; programs get updated based on new requirements all the time, and the reason for a software update is a "problem", otherwise you wouldn't be updating the software), the line(s) of code responsible for the current behavior and which must change to exhibit the new behavior are easy to find, easy to change, and, if necessary, easier to replace wholesale than lines of procedural "spaghetti code".

In software development, time is money; there are few if any direct materials costs for a software solution (mostly start-up costs), so the primary driver of the cost of a piece of software is how many developer-hours it takes to create it. Following OOP, I guarantee you, will require fewer developer-hours for any non-trivial program than ignoring it.

  • @ Keiths Good answer. One of the problems is that OOP seems to require more experienced or better programmers which are more expensive and hard to find. It's "cheaper" to hire junior programmers with no OOP knowledge. So for some leaders OOP is a luxury they can live without. – Tulains Córdova Oct 29 '12 at 16:52
  • 1
    There is no OOP in Tcl/Tk. No OOP in functional reactive graphics. No OOP in XAML. Why would you need OOP for GUI? Following OOP you'll need more developer-hours and you'll certainly increase maintenance costs. It is wise to avoid using OOP in any decently non-trivial project. – SK-logic Oct 29 '12 at 18:03
  • 1
    @user1598390: 'Have to finish their tasks' is fine until they are simply unable to proceed, either from lack of knowledge and vision, or because they have created such a huge pile of WTF that the development velocity is zero. – kevin cline Oct 29 '12 at 19:48
  • 2
    @KeithS First time I heard XML being called OO. I guess for some horrible broken definition of OO it can be. – Andres F. Oct 29 '12 at 21:59
  • 1
    @KeithS, XAML is, essentially, a huge set of mutually recursive algebraic data types (as any other complex XML language). There are no "objects" exchanging "messages". It is a domain-specific language with a very specialised semantics. – SK-logic Oct 30 '12 at 9:31

What kind of programs cannot be written unless you use OOP?

Because of Turing completeness there are none.

What kind of programs are not recommended to be written using non-OOP techniques? What kind of programs need OOP in order to even be written? What kind of programs would be too hard to write without OOP ?

OOP is a good when you have "natural" objects: GUI buttons, files, sockets, locks, etc. In pretty much every non OO language out there you see these opaque object wannabes called handles.

OOP is a mismatch when the design turns towards data transformation processes and doing things. You get stuck in Yegge's Kingdom of Nouns. Basically anytime you have a verb-able, or a verb-er you have strayed past the bounds of good taste in OO land.

That is why multi-paradigm languages are the way to go OO isn't the best tool for every job nor is any other approach. Not only that but there are relatively few applications that are single approach appropriate. So what we currently do is look at which approach is best for 70% of your app then shoe horn the other 30% into some horrible against the grain swamp monster of poor design.


OO is a way to organize programs. To make the case for OO, you need a big enough program that its organization is important (yes beginners are now drilled into OO way of thinking without any experience of programs big enough for it to matter, but those I meet often are like you, unable to explain why it is good, and thus unable to see when it isn't).

Obviously it doesn't depend only of the size of the program (with which metric BTW), but also a lot of what the program do. The easiest case of OO is probably simulators, there the OO way of thinking maps so cleanly to the problem domain that it is difficult to argue against. As a matter of fact, it was one of the use cases behind OO (Simula is one of the first OO language and it brought language support for techniques already in used but not formalized, and C++ started with the intention to reduce Simula's overhead).

Now, you'll have a very hard time to sell OO to a project leader experienced enough to see that what you are working on is a case where OO brings just overhead without compensating benefits.

  • like you, unable to explain why it is good I can, and have worked of big projects, but the points I make are not important for many project leaders: smaller code, more clean code, maintainability, etc. They only care about how fast you can code an app that cat run. They measeure how many "screens" you can create in a week. They equal "screens count" to project size. – Tulains Córdova Oct 29 '12 at 16:43
  • See my answer; OOP creates code that is easier to re-use, so the general-purpose code behind one screen can be abstracted into a base class that can then be used to create the next screen. The less you have to rewrite, the faster you can create new screens. – KeithS Oct 29 '12 at 16:48
  • 3
    From a workplace perspective, if the manager of a development team cannot intuitively grasp the advantages of OOP from both a developer and business perspective, get out now; this is a huge red flag of a bad place to be a coder. – KeithS Oct 29 '12 at 16:49
  • 1
    @user1598390 But OOP doesn't necessarily result in cleaner or smaller code; sometimes it's quite the opposite! You'll need better arguments if you want to convince your project leaders to use it. – Andres F. Oct 29 '12 at 22:01
  • You'll need better arguments That's precisely why I posted the question. – Tulains Córdova Oct 29 '12 at 22:08

Not the answer you're looking for? Browse other questions tagged or ask your own question.