What does it take to be a better OO programmer? [closed]

Question

I’ve almost 6 years of experience in application development using .net technologies. Over the years I have improved as a better OO programmer but when I see code written by other guys (especially the likes of Jeffrey Richter, Peter Golde, Ayende Rahien, Jeremy Miller etc), I feel there is a generation gap between mine and their designs. I usually design my classes on the fly with some help from tools like ReSharper for refactoring and code organization.

So, my question is “what does it takes to be a better OO programmer”. Is it

a) Experience

b) Books (reference please)

c) Process (tdd or uml)

d) patterns

e) anything else?

And how should one validate that the design is good, easy to understand and maintainable. As there are so many buzzwords in industry like dependency injection, IoC, MVC, MVP, etc where should one concentrate more in design. I feel abstraction is the key. What else?

Answer 1

you'll probably find that the elegant OO designs that you admire are not the first iteration, but result from several adjustments, refactorings, and fine-tunings

try to qualify why you think their designs are 'better' than yours, and adjust accordingly

the difference between an amateur writer and a professional writer is that the professional rewrites; the same holds for programming

Answer 2

[humor]

Object oriented skills can be learned from books and other resources. But if you are lucky, you inherit the skills from your parent. Most of the time it is a matter to provide and use the correct method. Be careful about the amount of arguments. Less is better.

Use the right names for anything. Use verbs as a method of activity. Use nouns for anything that needs to be remembered. Don't be too creative and keep your solution as simple as possible, else your users will be confusers.

It is also important to encapsulate the nasty details. And be sure to hide your private members for the general public else the unexpected behaviour will occur. Be also aware to catch your exceptional situation at the right level.

Rest me to press you to always test your units and to use the right interface to provide just enough handles for the happy user.

[/humor]

Answer 3

A little bit of everything. As for any language (verbal ou programming), the more you'll get exposed to it, the more you'll learn.

So read books, read your coworkers code. And at least as much important, learn new programming languages: they will broaden your vision, make you more critical of your own code and allow you to rethink your programming habits.

About design patterns, they are a de-facto standard way to work around common problems in common languages. You must know them to avoid reinventing the wheel and better communicate with your coworkers, but you should also see them as working around missing features in the languages you are using. The state machine pattern exists only in languages that don't provide them as builtins (not that I know a language that provides them, but you get the picture).

I would also add:

• always refactor if needed and time permits (harmless since you have unit tests to avoid regressions, of course).
• learn when to avoid inheritance (which is more often than you think).
• learn when to avoid OO (when it doesn't add any value).
• don't confuse OO with encapsulation (which is the main benefit of OO but is also provided by other paradigms).