so this is not < 64 words and less of a description of OO and more to your solicitation of "inspire me" of why you should care about it. The critical distinction IMHO:
Procedural programming is like a recipe- you program a sequence of instructions and while there can be if/then, loop and other logic constructs, it still runs like a "choose your own adventure" book. Since you have an imperfect view of the world and how requirements will evolve and you're providing what are essentially sequential instructions, it's brittle and unforgiving to unanticipated requirements.
OO is less about writing instructions and more about creating a representation of the world (or at least the aspects you care about) as objects and having them interact with each other to achieve things. Because you're modeling the entities involved and having them interact rather than imposing a prescriptive set of instructions from above, it's cleaner and more resilient to unanticipated requirements.
Granted it's overkill to use OO for simple tasks when a script will suffice. But if you're building a system that involves interaction of different entities and will need to be adapted & maintained it will almost certainly be more productive to use an OO approach. Btw, I found this book provides the most concise and useful primer on OO I've seen: http://www.amazon.com/Object-Technology-Managers-David-Taylo...
Procedural programming is like a recipe- you program a sequence of instructions and while there can be if/then, loop and other logic constructs, it still runs like a "choose your own adventure" book. Since you have an imperfect view of the world and how requirements will evolve and you're providing what are essentially sequential instructions, it's brittle and unforgiving to unanticipated requirements.
OO is less about writing instructions and more about creating a representation of the world (or at least the aspects you care about) as objects and having them interact with each other to achieve things. Because you're modeling the entities involved and having them interact rather than imposing a prescriptive set of instructions from above, it's cleaner and more resilient to unanticipated requirements.
Granted it's overkill to use OO for simple tasks when a script will suffice. But if you're building a system that involves interaction of different entities and will need to be adapted & maintained it will almost certainly be more productive to use an OO approach. Btw, I found this book provides the most concise and useful primer on OO I've seen: http://www.amazon.com/Object-Technology-Managers-David-Taylo...
sean