Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

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.

share|improve this question
5  
I suggest reading this summary 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 7:02
4  
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. –  Dokkat May 19 '13 at 8: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 8:17
5  
@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
4  
@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
show 8 more comments

marked as duplicate by MichaelT, GlenH7, World Engineer May 19 '13 at 13:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 4 down vote accepted

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.

share|improve this answer
    
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. –  m3th0dman May 19 '13 at 15:43
    
"only feasible to be build in an object-oriented approach" -1 for ignorance and flamebait. –  Jesse Millikan May 20 '13 at 5: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). –  m3th0dman May 20 '13 at 10:41
    
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
show 1 more comment
  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.

share|improve this answer
2  
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 –  delnan May 19 '13 at 10:11
add comment

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