Procedural versus Object Oriented Thinking. How do you know which is which?

Its often befuddling what is really meant by Object Oriented Programming, and what supposed to really make it special.

To truly appreciate OOP, it helps if one is familiarly ~w a r y~ of its opposites: Procedural Programming.

Its important to know and appreciate the difference. For as it turns out, just because you're familiar with a OOP language, doesn't mean you're thinking and writing in an OOP fashion.

So again, what does this all mean? I've already begun explaining what explained what OOP is. What is Procedural, and how does it compare?

Procedural Programming generally breaks down things functionally and then just goes with it. Imagine for instance, building an entire project in one massive main method().

Doable, but then what happens when something CHANGES? The true key of object oriented programming is in making things easy to change WITHOUT making code so convoluted over time, that it becomes difficult to maintain.

Object Oriented Programming principles thus evolved, with the three primary features to keep in mind being to keep your code well encapsulated (ie, protected against errors), with excellent use of polymorphism and inheritance to delegate behavior within your project. In this way each class may have only one reason to change if necessary, and when requirements change, all that's generally necessary is to add in additional plug ins that do not break what has already proven to work.

I know this all sounds greek now, but in future updates I intend to further break down the value of these terms. For now, think of it this way:

While procedural programming attempts to have one file do ALL the work...

Object oriented programming understands how to delegate the behavior of their project as "teamwork" amongst multiple files.

 ~Code Crunch Out~