First step in OOD?

Question

What is the frst step in OOD?

Answer 1

Practice, read broadly and more practice.

Especially with others to review and comment on approaches.

Reading should cover not just OOD, but also patterns to see how others have approached common problems.

Answer 2

There are no steps, it's not a process.

Answer 3

The answer is..

http://headfirstlabs.com/books/hfooad/

http://www.amazon.com/dp/0596008678/?tag=forelangstud-20

Answer 4

There are some preliminary steps:

• Understand OOD (in general)
• Understand the problem/application domain (the functional specification)
• Have a high-level/architectural design: know what O/S, libraries, frameworks etc. you can use

I then use a mixture of top-down and bottom-up development:

• Top-down: decide what components and what APIs (object interfaces) I would like to have in order to implement the application (and then, develope those API)

• Bottom-up: decide how to add new functionality to existing APIs (object interfaces), by adding new methods and new types of object (and sometimes splitting a large object into several smaller objects).

Answer 5

It's a lot of practice. The first thing is to get your mind around the way objects work--especially if you are a procedural programmer.

Practice making many small objects--I've literally never seen a system with too many objects; it's possible but I've never seen it. It should be really obvious when you need to put many objects into one, but it's not as obvious when an object should be broken up.

Ask an object to do something, don't ask for it's data. Try to avoid getters and setters and concentrate on methods where you ask it to do something with it's data. If you EVER see code like o.a=o.b+o.c or o.setA(o.getB()+o.getC() you are doing it wrong.

Constantly try to refactor out duplication. Rewrite your code repeatedly until there is none (or as little as possible). This will probably do more for your OO design skills than any other practice. As you get more knowledgeable, try refactoring things you didn't think you could refactor before. Anything that even looks like a pattern can probably be refactored. For instance here's a very basic example--if you had lines of code that looked like this:

a = b + c * d;
g = h + i * d;

Chances are there are HUGE refactorings missing in your code even though it doesn't look like it off the bat. You probably are missing an object that would hold a,b,c and a second instance would hold g,h,i, after creating these objects a bunch of stuff would factor into your new object. Learning to recognize new opportunities like this is critical.

I've been programming for over 20 years now, over half of it has been OO at this point and it seems like every few years I think I know it all--a year later I look back and realize how ignorant I was.