Main | 2.0 My bookshelf for OOA/D/P »

June 03, 2004

1.0 Selecting an OOA/D book

next post in category

One needs to understand OOA/D even if one is doing an OOP-based process like XP where one rarely does formal modeling. Even when one doesn't model, one needs to know how to abstract the problem space into classes, responsibilities, and collaborations. It's kind of like iteration, sorting, direct element access, and a whole bunch of other stuff software people tend to take for granted when programming -- the fundamentals are there but we rarely consciously think about them.

I would be cautious about book reviews. While they are useful for separating out the chaff, they may not be useful for choosing among the better books. That's for a couple of reasons. Reviewers who already use the author's methodology are much more likely to view the book in a kindly fashion. There is also a possible problem in the perspective. That is, the review may be quite accurate that it is a good book, but it is really about something other than what you want or it is focused differently than you would like (e.g., theoretical vs. pragmatic). Finally, there is the matter of style. One will tend to "click" better with one author than another if they have significantly different writing styles. In the end it is important to get the book that is the easiest read for you for a given subject matter. So it is important to go to the local bookstore, library, or university bookstore and browse.

I would look for a book with OOA and/or OOD in the title. But I would avoid books with 'UML' or a particular OOPL in the title. Such books are usually more focused on manipulating syntax than fundamentals. IOW, they do a good job of explaining how to represent your design but they don't help a lot in figuring out the right design in the first place.

Then look up certain groups of words in the index. In particular look for {class, object, instance}, {method, message}, {responsibility, attribute, method}, and {class, entity, type}. If any of these words are not in the index, put the book back on the shelf. Assuming they are all there, read the sections that define each term. If you feel the author has clearly defined each term and, more important, you feel you understand the differences between the terms, then it is problem a pretty good book on the fundamentals.

[If the author also explains Why the terms in each group are different and Why we should care, then let me know and I will buy the book!]

There one other thing to watch out for. If the index has more entries under 'type' than under 'class', put it back on the shelf. A type system is a mechanism for implementing an OOA/D class system at the 3GL level. So if the author is more interested in types than classes, it indicates the author is really more focused on OOP than OOA/D.

next post in category

Posted by HS in Books | Permalink