Objects: Why are they useful?

[eluser]Nick Husher[/eluser]
From Wikipedia: "Object-oriented programming is based on several techniques, including encapsulation, modularity, polymorphism, and inheritance."

Encapsulation: this is the practice hiding raw data in cases where the raw data isn't always important, or would be harmful if modified incorrectly. Let's say you're building a mechanism for storing data for quick access. You could have an array with various search functions applied to it, or you could just store it in a binary search tree and let the user modify it as they please. But then you've tied yourself to that implementation, if you find out later that a BST is significantly inferior to a red-black tree or radix tree, you're stuck reimplementing a ton of code where you assumed that the underlying structure was a BST. If you were using an object, how you're storing the data specifically doesn't matter, you just have a QuickAccess object with an insertData function and a retrieveData function.

Modularity & Polymorphism: This is a practice that allows you to replace one object with another without upsetting the codebase. In a procedural codebase, one piece of the code is often dependent on other pieces of the code existing or operating in a certain way. With OOP, one object doesn't know or care what other objects are doing or how they're doing it, as long as they properly implement a common method of communicating (an interface, in Java terms). One good example is that of a stream reader in Java--the various kinds of stream readers can open HTTP connections, load files, or read user input. If your designing your code for reuse, you might want to use it with different inputs, in which case all you have to do is swap the streamreader in a few places rather than reimplement your code to handle different kinds of connections.

Inheritance: allows you to save yourself the task of repeating code. If you're building a system that has related objects--maybe you're designing a UI library and you have a radio button and a checkbox widget. They're very similar in concept (they both have an 'on' state and an 'off' state, they both have an associated value, etc), so it would be easier to develop one object that implements common functionality and then create two child objects that implement the specific functionality of each than to write two different sets of functions.

There are ways to do all of the above things with clean coding and code conventions in procedural code, but there's less of an incentive to do it. To create shared interfaces and modularty in a language like C takes a fair amount of forethought and documentation, which are things that easily kill the momentum of a project. With a strictly OOP language (like Java), the above principles flows naturally out of the language. There's nothing you can do with an OOP language that you can't do with a non OOP language, but the level of abstraction that it gives you implies a certain quality of coding that's difficult to replicate in a non OOP environment.