First step in OOD?

What is the 开发者_如何学JAVAfrst step in OOD?

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

The answer is..

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

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

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.

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.

the first step is object oriented analysis - its aim is to identify the objects that make up a system and how they interact; given this knowledge you can then specify the behavior of the object (the interface methods) and then the internals (what are the required data members of an object)

The design process produces a number of diagrams - these are tools that are supposed to help with working out the details of the system :

first come a set of 'use cases' - a use case is a verbal description of a scenario that is implemented by the system (one is supposed to pick the most substantial ones); these are then used to identify the main actors and concepts which are supposed to map to the classes of a system. This understanding is then refined by working out 'object interaction diagrams' 'class diagrams' and 'sequence diagrams' sometimes state charts are used to visual state machines - these diagrams are tools to gain an even better understanding of the system, as a result you have a sufficient understanding of the system to write the class header files/class definitions. There are no fixed rules which one of these diagrams come first, these are used as appropriate.

i found the following book very useful :

OBJECT-ORIENTED ANALYSIS AND DESIGN With applications (second edition) by Grady Booch

the book goes through the process of designing several example systems step by step (i think it is enough to read the design process for these example systems); One minor problem is that the notation used in this book is a bit dated : modern practice is to use the UML notation for diagrams, however the book still uses the older Booch notation. The strong point of the book is that it is always explaining each concept by working through concrete examples.

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).

The first step of OOD are the OOD principles. Check out The Principles of OOD.