19

Somewhat inspired by this question: For what common problems is functional programming not a good fit? - but nevertheless a question which I always wanted, but was too afraid to ask.

I've been in ... well, let's call it engineering software development practically all my life, and in all that time, although OO had always been there (well, most of that time) I've never had the need to use "its ways", nor to learn that paradigm. We've always used rather simple program structures, routines/functions/modules and although it is opposite to today's best practices managing those programs (programs up to roughly 300k LOC, nothing too big) never proved to be difficult, let alone impossible.

So I wanted to ask you, what would be the sorta problems for which object oriented paradigm would not be a good choice? In comparison to procedural programming ?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
Rook
  • 19,861
  • 9
  • 53
  • 96

7 Answers7

8

Object oriented programming is procedural programming. The thing that makes OO object oriented is, as Robert Harvey mentions in a comment, that OO abstracts data in a particular way (to wit: bundling the functions that operate on a structure with that structure).

William Cook explains the difference between objects and abstract data types nicely.

So at the risk of sounding facile, I'd say that objects are not a good fit for when you need to easily extend the (number of) operations that perform on your data, and you don't need to have varying implementations of your data. Having said that, there are things you can do to bring the two closer together.

Frank Shearar
  • 16,643
  • 7
  • 48
  • 84
5

The main value of OO is that it provides decoupling among components of your system, making it easier to write DRY code and adapt to specific types of change that you plan for in your design. The cost is that it adds layers of indirection, which can make the code harder to reason about, less efficient and harder to modify in unanticipated ways (the ways that aren't aided by the decoupling your design provides). It is therefore a waste of time for any subproblem where you don't need the decoupling it provides. Specifically, it is a waste of time if you can easily write DRY code without it and don't anticipate any specific requirement changes that would benefit from the strong decoupling that OO provides.

dsimcha
  • 17,224
  • 9
  • 64
  • 81
  • 3
    Decoupling is a nice side-effect of OO programming done well, but I would say that the primary benefit of OO programming is organizational encapsulation of functionality. – Robert Harvey Oct 28 '10 at 02:31
  • 1
    @Robert Harvey: I have a different point of view of the same reality: for me organizational encapsulation of functionality is the means for obtaining decoupling which in turn allows for reusability. – mouviciel Oct 28 '10 at 09:09
  • @Robert Harvey: Coupling and cohesion are two ways of looking at essentially the same thing, which is a sort of locality where you can understand something without needing to understand too much else. – David Thornley Oct 28 '10 at 17:20
  • I think part of the disagreement is that, IMHO using OO means that you use polymorphism and inheritance, at least of interfaces, extensively. By my definition of OO, for example, C# or D structs, or using only final/sealed classes and no interfaces would be considered just syntactic sugar plus a few access control attributes, not real OO. – dsimcha Oct 28 '10 at 18:06
3

concurrency: the locking mechanism seems kind of problematic; only some very good developers are put to work on the threading part of projects

extending: don't know how extandable the current OO languages are. only know that Java is bad. therefor DSLs (domain-specific languages) have to be implemented as Frameworks. Clojure on the other hand (that is functional), has macros.

Belun
  • 1,314
  • 8
  • 15
  • +1 for the locking argument - the evidence seems to be that locking logic on mutable objects becomes unmanageably complex beyond a certain point in OO languages – mikera Jun 14 '11 at 21:52
  • +1 for mentioning concurrency. A concept similar to objects but supporting concurrency is that of an actor. Actors are concurrent entities that communicate by exchanging asynchronous messages. – Giorgio Mar 09 '13 at 13:04
  • Ditto on concurrency; I've made the statement that OO, in encouraging you to identify / maintain discrete units of *state*, actually encourages concurrency issues. – user1172763 Mar 14 '16 at 20:08
0

Most programmers, OO savvy or not, uses concepts like abstraction, information hiding and interfaces in their code. OO languages simply makes that easier since these concepts are already built-in. You don't have to invent them yourself.

A core algorithm like qsort() uses abstractions for comparison of arbitrary objects. fread() uses an interface to abstract away the details of the stream etc.

From that standpoint I find it hard to come up with any particular problem that are better solved with a non-OO approach.

Martin Wickman
  • 13,305
  • 3
  • 31
  • 66
0

Object Orientated programming can be used to model your domain. The classes can be used to represent the state and behaviour of entities, aggregates, collaborations, services within your domain model. Moreover, the method invocations and protocols between the objects can model the dynamic relationships between entities.

I have found it to be a useful way of producing a DRY model that can cleanly represent the rules and behaviour of your application in a way that is decoupled from technical issues (such as the use of a database, or a message queue, or the fact it is a web application). A good book on the topic is Domain Driven Design

An important thing to note here, is that the "entities" I mentioned above do not have to map onto real world objects! They can represent abstract parts of the domain of your application to.

So, if that is what Object Orientated programming is good at; what is not good at? Well, anything where the domain model cannot be expressed well as objects. For instance, some mathematical, (statistical, logic, etc) or technical (e.g. a compiler) programs are expressible better in different styles. I have found that for business workflow applications a combination of OO and custom DSL techniques have been very effective in allowing us to model the kinds of relationships and events that occur in business process. For program verification and automated proof checking a functional approach is often used, because its pure functions allow more direct mathematical reasoning.

flamingpenguin
  • 2,821
  • 16
  • 12
0

I think that when building systems that combine other systems through web apis (rest, xmlprc, plain curl/wget) you can write OO wrappers but it's clearly just a convenience. If the web service to be used is simple, and it's just a matter of one or two lines, then OO is too much. If on the other hand you end up having to wrap a complex web api (like Amazon AWS for example) then it's nice to have a wrapper library (like boto in python for AWS).

Thoughts?

Christopher Mahan
  • 3,404
  • 19
  • 22
0

The PURE object oriented languages are not suitable for many cases. Because there are some criteria to be fulfilled for being pure object oriented language. See-
https://stackoverflow.com/questions/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

But most widely-used programming languages are multi-paradigm. They incorporate many non-OO features to encounter various types of programming and development issues. C++, C#, Java or Ruby all have non-OO functionalities. So, they can face issues that pure-OO is not good at.

Community
  • 1
Gulshan
  • 9,402
  • 10
  • 58
  • 89