I'm trying to get a better grasp of the applicability of object-oriented programming and design. I'm curious about some examples of situations where object orientation is not simply inefficient or overkill, but highly inappropriate and entirely not recommended.

Nowadays it seems that OOP can be applied to a very wide range of software modeling problems, but I'd like to know when OOP would be one of the worst ideas of all paradigms.

closed as too broad by gnat, user40980, user22815, durron597, Thomas Owens Jul 14 '15 at 14:22

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Any program which independently fits on a chip. – toplel32 Jul 13 '15 at 18:06
  • @toplel32 Could you please elaborate why? Code size and resource constraints? You refer to all chips or to certain types of chips? – Gabriel S. Jul 13 '15 at 18:09
  • Any problem in which you have a fixed set of types and a growing number of operations that process them: using an object-oriented approach you would have to add a method to each class each time you define a new operation. – Giorgio Jul 13 '15 at 18:10
  • @Giorgio You refer to an OOP abstraction of that data type offering an interface and several implementation classes, so that a change in the interface (the new operations) force the change to ripple into all those classes? – Gabriel S. Jul 13 '15 at 18:13
  • 2
    @Gabriels.: Yes. OOP shines in the dual situaton: a stable interface with a growing number of classes implementing it, e.g. widgets in a GUI library. – Giorgio Jul 13 '15 at 18:17

First of all, don't confuse OO modeling with OO programming. Most modern programming languages are more or less OO and can be used to implement most designs whether they have been derived using OO modeling or not. I can write a program following a relatively procedural design (or event-driven, or some other style) and still use Java Collections with their practical OO interfaces.

Now for modeling, I'd say don't use OO in domains where more specific frameworks are already established. For example, if you deal with an event-based problem, then it makes sense to describe your design using events (not classes) as a building block and only for implementation (if you use an OO language) decide on how to map that to classes or objects. For example, you could find that all your events need the same set of methods, so you implement them all using one class.

In my experience it is actually always better to figure out notions of design using concepts from the application domain and only in actual implementation decide what should become a class or a subclass and what are important methods. Classes and methods, in my opinion are much more useful at structuring code than at structuring your customer's problem.

  • +1 I'd add more specific frameworks or languages are already established – Tulains Córdova Jul 13 '15 at 19:39

There are several ways to look at this. One way is from the point of view of data abstraction. (I'm going to ignore looking at this from the perspective of programming paradigms, since @Robert's answer already does a good job.) The two most popular forms of data abstraction in use today are Abstract Data Types and Objects. (Actually, there is a rather popular third form: no abstraction at all.)

The main difference between ADTs and Objects is that ADT instances hide their representation from instances of other types but not from instances of the same type, whereas objects also hide their representation from other objects of the same type. (If you are familiar with Java, that's the difference between classes and interfaces, classes define ADTs and interfaces define objects.)

What this means is that because of the higher level of encapsulation, OO has the potential to be more flexible and extensible. However, algorithms which need access to the representation of two objects are simply impossible to implement. For example, you cannot efficiently concatenate two doubly-linked lists in OO, because you need access to both the first list's tail's next pointer as well as the second list's head's prev pointer. If you call the first list's concat method, it has no access to the second list's internals and vice versa, the only way to do this efficiently is by one of the lists exposing its internals to the other one, i.e. breaking OO encapsulation. (You can of course concatenate two lists by iterating the second one, i.e. do it in O(n), but you can't do it in O(1).)


Consider the three pillars of OOP:

  1. Encapsulation: The capability to hide data and instructions inside an object

  2. Inheritance: The ability to create one object from another

  3. Polymorphism: The ability for objects of a derrived class to override/extend/inherit properties and methods from a base class

If these benefits do not offer any real value to solving the problem at hand, you can argue that perhaps OOP is not the ideal choice, or at least not necessary.

In practice, the benefit that comes with well-designed and well-written OOP rarely justifies the "overhead" when working with relatively small applications or applications that are resource-constrained. In the wild I've seen many ETL processes built in languages like C# and Java that don't necessarily follow the object-oriented paradigm. Yes, there is a "class" because of the constraints of these languages, but all methods are made static and exist within a single class called Program.(cs/java) that acts as the application's entry point.

Truthfully it's difficult to think of situations where OOP is the absolute worst of all available programming paradigms, but there are cases where it is not the most ideal paradigm. One could say that yes, an object-oriented paradigm is not always ideal for a situation that lends itself to an event-driven or procedural paradigm, but it's difficult to say whether it would be more or less ill-suited to the situation than, say, a functional paradigm.

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