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.

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.