Generally i think about my problem solutions in terms of objects, and the code naturally comes out that way. It is a bit different way to approach a problem; having been brought up in the traditional procedural coding style I can tell the difference.
OO code tends to be more complete. When I design my objects I tend to come up with utility functions. For example I write a toString() function to output my object's property values. Really good for troubleshooting and it's there for the next guy if he needs it.
OO code tends to be more organized. Instead of a mass of variables I group them where it makes sense and make objects and even sub-objects. This organization tends to pay off later when I'm referenceing things all over the place. Data is easily passed "in chunks" because it's all one object.
When I am thinking about this object and what IT should do I tend to write more rigorous validation code; due to OO principles such as "always keep an object in a valid state."
OO think makes you a better programmer
A lot of what goes into good object code writing is just good coding practices period. I think "my object must do A, B, and C so I write methods that do A (and nothing else), B (and nothing else), and C (and nothing else). There you just applied the principle of "maximize cohesion and minimize coupling". Miraculously this makes code easier to read, easier to modify, easier to test.
OK, you do write more code
I find this to be true. This is a natural consequence of writing better, more robust code, but it goes against the grain of web programmers. I think we get brainwashed into thinking we must write the absolute minimum code in order to "save bandwidth." Talk about your urban myths! I write so much client-side JS that fellow programmers give me "that look" (really, they do!). But no one has yet proven the down side. In the mean time I've got solid code! Can't argue w/ success.
OO code is often easier to write
When your data is organized into objects, and the functions that go with it are each "singular in purpose" (remember "maximize cohesion" above?); I've often found that the methods I write are pretty small. Oh I might have a lot of methods, but they tend to be smaller and/or less complex.
Again we get into the "less code is better" bass-ackwards way of thinking issue. "I'll save some keystrokes by putting 3 things into one function - that's good". NOT!! Writing smaller, more focused - singular in purpose - makes each function much less complex, thus easier to write, debug, read, etc.
OO code is a little more reusable
Variables and methods are encapsulated w/in the object so if you include the code in an HTML page, you don't get variable name conflicts.
A well written object stands alone. It has all the methods it needs to do what it does. These methods do what they say they do and nothing more. A well written object tends to not need more code written for it for the next time it's used.
OO code is easier to use
After we invoke the buzzwords encapsulation and abstraction we admit to ourselves that at some point we do have to write down-and-dirty detail code OF the object. BUT once that's done the magic happens. You will pleasantly discover that writing the code using the object looks and feels "higher level" than you'd expect.
Because you wrote and debugged the core object code first you find yourself focusing on the highlevel control code rather than getting distracted by trying to write and debug high level and detail code all at the same time.
After some practice with this stuff you begin to notice some things:
* your code is more modular because you wrote it "from the ground up".
* You loose the "I'm trying to write all the code all at once" feeling.
* You surprise yourself one day realizing you wrote perhaps your most complex code yet, but it works!
* Testing is easier
* You can tell you're putting out consistantly better quality code.