11

It's fairly obvious that OOP is viewed as a sort of silver bullet of programming today. In any computer science course, the merits of OOP are heralded.

I would like to know why people like OOP. To be honest, combining procedures, types, and data structures into a single conglomerate seems bad to me. I'd much rather view data as simply data. I like to be able to think that I will pass the right data through a function and get the right output, and not have to consider that the data is capable of operating on itself.

Also, I want to know if there are any good examples of robust programs written specifically with or without OOP, that have their source code available.

jepugs
  • 442
  • 1
  • 4
  • 10
  • 7
    I suggest reading [this summary](http://stackoverflow.com/a/6723679/475458) of the philosophical and strategical differences between functional and OOP styles, for a start. It begins to get at what I want to say, which is the less state you need to track, the better functional-style is; and conversely, the more state you need to track, the better OOP is. In general OOP helps you not blow your foot off as system complexity goes up. (this assumes a sane OOP system -- eg. like Python, unlike C++.) As complexity goes up, you do more stupid things, and the safety provided by OOP is more valuable. – kampu May 19 '13 at 07:02
  • 5
    OO is overrated. It just solved problems that **needed** to be solved when they needed to be solved. Then it became just too popular to be stopped. But it is not required to solve those problems and it is not the best in solving them. – MaiaVictor May 19 '13 at 08:11
  • @Dokkat If you have better idea, then go ahead and implement it. I bet many people would love to find something better than OOP. But right now, OOP is best we can have to fight complexity of software. If understood and used correctly. – Euphoric May 19 '13 at 08:17
  • 'Good' in which context? It's great in a wide variety of contexts, and bad in some specific contexts, where e.g. Domain-Specific Languages are better. @Dokkat: solving the problem is only 15% of software. Doing that in a way that is legible, maintainable, debuggable, extensible, portable to future coders is a bigger (more expensive) issue. That's why OO has value. Sure, you could code it in PL/1 instead. That would be inferior for all these reasons. – smci May 19 '13 at 09:13
  • 7
    @Euphoric, there are dozens of better approaches. OOP is pretty useless outside of a very narrow field (namely, agent-based simulations). OOP does not help fighting the complexity - modularity does. People too often give credits to OOP which in fact belong to modularity, a much more generic concept. – SK-logic May 19 '13 at 10:48
  • @SK-logic Then name those approaches. And its not about modularity. its about encapsulation and polymorphism. – Euphoric May 19 '13 at 10:58
  • 5
    @Euphoric, as I said, there are *dozens* of models. You should not use a single approach for everything, you have to pick up the right one for each problem domain. A Language-Oriented Programming is a kind of a unifying approach, which allows you to choose the right methodology and the right semantics for each little sub-task. OOP is just one of the tiny tools in this huge model, barely useful. And no, you're wrong, all the "complexity"-related properties of OOP are nothing but modularity. And in OOP it is pathetic - compare it to, say, SML module system. – SK-logic May 19 '13 at 11:04
  • @Euphoric OOP is a good approach in many cases but by no means universal. Do you think for example that the firmware in your washing machine or toaster will be OO? And a big drawback to OOP is that, comparitively speaking, it is big and slow. If performance is your #1 priority you would probably not go OO. – PeteH May 19 '13 at 11:55
  • @SK-logic Would you mind fleshing that out into an answer? I'd appreciate that! – phant0m May 19 '13 at 12:20
  • @PeteH Actually there is no problem using OOP for firmware of waching machine and toaster. And OOP is not slow. Its just that most common languages (like Java,C#, Python) are regarded as slow. – Euphoric May 19 '13 at 12:23
  • "Object-oriented programming is an exceptionally bad idea which could only have originated in California." — Edsger Dijkstra. (Sorry, couldn't resist! :D ) – Andres F. May 19 '13 at 16:50
  • @PeteH I'm no fan of OOP, but performance is not a good criticism. OOP has pretty performant implementations. The criticism is that it's not a particularly good _paradigm_, design-wise. – Andres F. May 19 '13 at 16:54
  • I want to add my comment to this. OOP is not a silver bullet at all. However, people can think out the structure of their programs easily in many situations by thinking like this. If you don't feel comfortable to implement your program in OO structure, don't bother. – Abby Chau Yu Hoi May 20 '13 at 10:29
  • You may find this summary interesting: http://www.yegor256.com/2016/08/15/what-is-wrong-object-oriented-programming.html – yegor256 Aug 19 '16 at 17:21
  • @MaiaVictor This is COMPLETELY off topic but I was wondering how your name is pronounced? I've never heard of that name before. – MarcusJ Feb 01 '18 at 16:38
  • 1
    @MarcusJ It is Victor Maia, a common Brazilian name. You can hear it by typing "Vitor Maia" (mute "c") on Google translate for Portuguese (br). – MaiaVictor Feb 01 '18 at 18:52
  • @MarcusJ why asking on such an old question? I didn't even remember it. – MaiaVictor Feb 01 '18 at 18:53
  • I searched up on why OO sucks cuz it annoys me the giant circlejerk on it. – MarcusJ Feb 02 '18 at 03:50

2 Answers2

8

To be honest, combining procedures, types, and data structures into a single conglomerate seems bad to me. I'd much rather view data as simply data. I like to be able to think that I will pass the right data through a function and get the right output, and not have to consider that the data is capable of operating on itself.

Here you ignore or seem not to understand one of the basic pillars of Object-Orientation and that is encapsulation. The point of OOP is that there is no data structure and there are no algorithms when you use the "conglomerate"; there are data and algorithms only when you build it, and only you - the creator of the class - should know or care what algorithms or what data structures are used. This, combined with the other 2 (polymorphism and inheritance - PIE) provide a great reuse mechanism and a great abstraction.

The object itself provides a great abstraction; it exposes (or ideally should expose) only behavior, which means that it can easily be changed with another object with similar behavior or it can be reused in another place which requires similar behavior. This leads to what is probably the most important thing about OOP - modularization. Basically your program becomes a bunch of loosely coupled modules that only communicate with each other via message exchange, which is a great improvement over the old way of programming where you have data and separately algorithms operating on that (global) data.

This lead to the production of frameworks, which actually do most of the job leaving the programmer only with the job of customizing with business logic rules and providing hooks into it. This greatly reduces programming time and makes feasible the creation of larger and larger systems.

From another point of view, object oriented programming greatly eases the modeling part as objects can be modeled more naturally into programming constructs.

But OOP is no silver bullet; as Fred Brooks famously said: "there are no silver bullets". Much of the theory about ideal OOP is not applied correctly which yields bad programs.

Also, I want to know if there are any good examples of robust programs written specifically with or without OOP, that have their source code available.

The thing is that there are a large set of projects that are only feasible to be build in an object-oriented approach mainly because of inherent complexity.

Random42
  • 10,370
  • 10
  • 48
  • 65
  • Thank you, before I looked at objects as being a form of data, but now I see that that's not the case. I'll cautiously move into OOP, but I'll keep my objects and my data separate. – jepugs May 19 '13 at 13:46
  • @jepugs Hope it helped; keeping objects (algorithms I suppose) and data separate isn't really proper OOP. I suggest you read some books about OOP and OOP Design. – Random42 May 19 '13 at 15:43
  • 3
    "only feasible to be build in an object-oriented approach" -1 for ignorance and flamebait. – Jesse Millikan May 20 '13 at 05:30
  • @JesseMillikan Only feasible not necessarily from a technical point of view but from management also; it is more easy an cheap to implement a large server in Java than in C or Haskel for example (even if we disregard the frameworks). – Random42 May 20 '13 at 10:41
  • 3
    Make that ignorance, flamebait and baseless assertions. A large server, you say? Like one running Linux, Apache, PHP and MySQL? – Jesse Millikan May 20 '13 at 13:38
  • @JesseMillikan So you say that C or another non-OOP language is perfectly valid for building a large enterprise server (not LAMP - those aren't so large) and is a usual option for anyone desiring to build such a server? – Random42 May 20 '13 at 13:58
  • 1
    @m3th0dman funny that you mention a language of the *functional programming* type as an example for your argument about manageable OOP code ; ) – Zelphir Kaltstahl Aug 08 '16 at 15:05
  • K, well in practice OO uses far more memory (it by definition duplicates every function for absolutely no reason, taking up more memory), which then increases the pressure on the caches, slowing down execution, all for absolutely no benefit, or reason. – MarcusJ Feb 01 '18 at 16:40
  • I agree that OO is great because of the encapsulation it allows, but I don't agree that OO itself lead to frameworks, or that frameworks are a better technique for easing programming than modules. Java itself lead to the proliferation of frameworks, because java itself is so constraining it often needed other technologies to remain productive. – B T Aug 20 '18 at 21:09
3

  1. Modularization: - Decompose problem into smaller subproblems that can be solved separately.

  2. Abstraction (Understandability): -Terminology of the problem domain is reflected in the software solution. (Individual modules are understandable more easily by human readers.)

  3. Encapsulation (Information Hiding): - Hide complexity from the user of a software of SDK. Protect low-level functionality.

  4. Composability (Structured Design): -Interfaces allow to freely combine modules to produce new systems.

  5. Hierarchy : -Incremental development from small and simple to more complex modules.

  6. Continuity : -Changes and maintenance in only a few modules does not affect the architecture.

omarqa
  • 442
  • 3
  • 7
  • 5
    Modularization is older than even structured programming; it is orthogonal of the paradigm. Same for abstraction, composability. Now, you may argue that OOP does these things better than other options, but that is an order of magnitude less convincing and still quite arguable. I've never heard 5 and 6 cited as advantages, but "Continuity" sounds like a consequence from modularization and abstraction, and "Hierarchy" sounds like it's paradigm-independent as well (in fact, it sounds so trivial that I can hardly imagine a scenario where it's not feasible). -1 to counter +1 –  May 19 '13 at 10:11
  • If using hierarchy as an argument for OOP, one should keep in mind, that high object hierarchies are anti pattern to be avoided, because of them not being very maintainable. – Zelphir Kaltstahl Aug 08 '16 at 15:08