Excellent, language neutral book for burgeoning OO programmer. You will not learn how to program, but how to design your classes.

If you're a software architect you've probably read this book 100 times... If you haven't you better get started. This came highly recommended by a good friend - I haven't been able to thank him enough. Meilir's light readable style and profoundly deep understanding of the subject makes this book as accessible to a beginner as it is fun to read to an expert.

If you're a software architect you've probably read this book 100 times... If you haven't you better get started. This came highly recommended by a good friend - I haven't been able to thank him enough. Meilir's light readable style and profoundly deep understanding of the subject makes this book as accessible to a beginner as it is fun to read to an expert.

Maybe, just maybe, Page-Jones might update this book to account for the release of UML 2. But then again, this book is still very pertinent, regardless of which version of UML you are currently on. The descriptions here let you describe many types of object oriented software packages, in a useful and concise manner. One that can be readily understood by others who have not worked on coding the packages. Plus, of course, another great advantage of being able to use UML is during the planning and coding of those packages.

While you can certainly do OO design without UML, Page-Jones suggests why UML can aid in the understanding.

Any positive thing, and there is a lot of them so far (I'm in page 65), in this book is a merit of the author, not of the subject itself, OOP. I've been a programmer (after a few other things, like a regional planner, by example) almost for the last 20 yrs.
I've been a witness of many revolutions: somebody remembers OS/2 and the Data Manager?, or the AI discussions, that filled thousands of computing papers and magazines, about which one is better: Prolog or LISP?
I remember the words of a scientist: "the best language is your mother tongue, that you naturally use for discuss and analyze problems, and for formulate solutions to them".
Only one little difference: those were freedom times, no software or hardware company had the total control, programmers, worked individually but at the same time, collaborated with each other, even being a rare species, didn't charge a thousand/hour, and managers weren't so worried about controlling and slavering programmers, which is the real motive behind of all sort of "magic" software development paradigms today in place: to take out from programmers the free spirit, the freedom of solve the user's problem the best way the programmer, him or herself, can figure out.
These days, the cool thing is project management, team meetings, lot of vacuum methodologies, infinite and continuous upgrades of tools and platforms. I'm sure 100% that in the core of the code of the couple of dozens of real outstanding software products nowadays, call it AutoCAD 25 or Doom 3, there are two or three programmers, the AUTHORS, and another 15 or 20 people around, doing complementary tasks, along the cycle of life. Everything else is market "hoopla", busine$$ in the best tradition of the snake oil and hair tonics.
Not a long time ago died Edgar (Ted) Codd, I think he couldn't stand to see how the worst database in PC history: Access, a database software packaged for secretaries and bookkeepers, became dominant in the desktop scene, and has yearned billions of dollars to computing moguls. As his colleague and another database giant, Chris Date, quoted: "sad thing is he never made money (and the side plates: fame, glory, etc.) from his ideas, others did."
I have to laugh every time I see some PC wizard going to the DOS command (in every Windows incarnation more hidden than in the prior) to do some obscure and arcane ritual, with the same looking in his face as he were landing in Mars or Jupiter.
Sorry for the rampage, once in a while you have to let it go.
As John Dvorak said a little while ago: "I don't get it". All I ask God is HE provides me the strength to hold another ten years, and then retire, to read historic novels.

Any positive thing, and there is a lot of them so far (I'm in page 65), in this book is a merit of the author, not of the subject itself, OOP. I've been a programmer (after a few other things, like a regional planner, by example) almost for the last 20 yrs.
I've been a witness of many revolutions: somebody remembers OS/2 and the Data Manager?, or the AI discussions, that filled thousands of computing papers and magazines, about which one is better: Prolog or LISP?
I remember the words of a scientist: "the best language is your mother tongue, that you naturally use for discuss and analyze problems, and for formulate solutions to them".
Only one little difference: those were freedom times, no software or hardware company had the total control, programmers, worked individually but at the same time, collaborated with each other, even being a rare species, didn't charge a thousand/hour, and managers weren't so worried about controlling and slavering programmers, which is the real motive behind of all sort of "magic" software development paradigms today in place: to take out from programmers the free spirit, the freedom of solve the user's problem the best way the programmer, him or herself, can figure out.
These days, the cool thing is project management, team meetings, lot of vacuum methodologies, infinite and continuous upgrades of tools and platforms. I'm sure 100% that in the core of the code of the couple of dozens of real outstanding software products nowadays, call it AutoCAD 25 or Doom 3, there are two or three programmers, the AUTHORS, and another 15 or 20 people around, doing complementary tasks, along the cycle of life. Everything else is market "hoopla", busine$$ in the best tradition of the snake oil and hair tonics.
Not a long time ago died Edgar (Ted) Codd, I think he couldn't stand to see how the worst database in PC history: Access, a database software packaged for secretaries and bookkeepers, became dominant in the desktop scene, and has yearned billions of dollars to computing moguls. As his colleague and another database giant, Chris Date, quoted: "sad thing is he never made money (and the side plates: fame, glory, etc.) from his ideas, others did."
I have to laugh every time I see some PC wizard going to the DOS command (in every Windows incarnation more hidden than in the prior) to do some obscure and arcane ritual, with the same looking in his face as he were landing in Mars or Jupiter.
Sorry for the rampage, once in a while you have to let it go.
As John Dvorak said a little while ago: "I don't get it". All I ask God is HE provides me the strength to hold another ten years, and then retire, to read historic novels.

The author uses his own dialect of UML in too many places, Skips Use-Cases all together. The examples are too simplified. It is not fundamental OO because he doesn�t define OO terminology as it is in the standards. He gives his oppinion on everything and this colors his explanations and examples.
If you are looking for a beginners UML or OO forget about this book. If you like to read another angle on some parts of the OO or some UML diagrams then this is your book.

Object-orientation is often criticized for lacking a theoretical foundation. While patterns proliferate, principles remain elusive. But the pursuit is on, and Mr. Page-Jones leads the hunt with this fine work.

He catalogs attributes of object-oriented design by which we may intelligently discuss their quality: connascence, encumbrance, cohesion, type conformance, contravariance, covariance, closed behavior, ideal states, ideal behavior, and others. Patterns and anti-patterns are also exhibited, but the distinctive feature is the presentation of principles that all patterns must obey.

Each chapter begins with an overview and ends with a summary followed by exercises with answers. Be sure to read them all. The exercises are interesting, and the "summaries" sometimes (Chapters 5 and 6, for example) introduce new concepts.

The glossary is excellent. The bibliography is unfortunately not annotated. Some passages are over-peppered with footnotes, especially when their point is merely humorous. Overall the footnotes are valuable and the humor is appreciated.

The text takes care to reference backward and forward to related topics, helping readers to trace their own threads.

Some readers want more details about UML. Part II clearly describes a basic subset of UML probably sufficient for 90% of business scenarios, but many of the fine points are omitted.

Part III treats the reader to a series of thought-provoking discussions of the qualities of good software design. Some of the thoughts provoked involve differences of opinion that this reader would like to describe below. Before doing so, however, he must emphasize first just how valuable he found the time spent considering the ideas of Mr. Page-Jones and how strongly he advises others to spend their own time in a like fashion.

This reader was taken aback by the following advice: "Even when designing non-distributed applications, you should try to split a large class (one like Customer . . .) into several 'aspect' classes, using the composition construct to link their objects. For example . . . CustomerFinancials, CustomerShipping, and CustomerProfile. An object of class Customer would contain references to the objects of all three (p. 204)."

There could be in some cases justification for such splitting, but none is offered here. The point of the classes is to represent subjects in the business domain, not to categorize their attributes by their primary use. (And what's the difference between a Customer and a CustomerProfile anyway?)

The composition construct is intended to represent composites from the business perspective, not at the level of the meta-data. While it might be true that the DATA ABOUT the Customer is composed of financial attributes and shipping attributes, it is not true that the Customer ITSELF is a composite of things called "shipping" and "financials." The advice makes the classes model the data about the customer instead of modeling the customer itself.

Another similar pollution of the business perspective occurs in a class diagram showing class ResourceType as aggregate of ResourceInstance, accompanied by the explanation, " . . . all three class diagrams deal with types, each of which aggregates a bunch of instances (p. 391)."

Now, a "type class" always has the potential to be used to define aggregates of the objects of the "instance class." Whether it is in fact so used in a given business depends on the existence of a business operation appropriate for every object of the "type class" and affecting every object of the "instance class". But what operation can we define for class ResourceType equally appropriate for Employees, Rooms, and Whiteboards--and affecting every instance of one of them? Operation PAINT might apply to Rooms, but not to Employees. FIRE to Employees but not to Rooms. Even ERASE would not apply to every Whiteboard simultaneously.

If the business does not have aggregate operations on objects of a type, then the type should not be modeled as an aggregate. Every association having a maximum multiplicity of 1 for one class and * for the other is not an aggregation.

This reader read with great sympathy while Mr. Page-Jones bashed the "know how" cliché of object-oriented design, as in "a document should know how to print itself (p. 250)." In a subsequent footnote, he continues in the same vein: "I find this anthropomorphic view of object orientation to be specious and irrelevant (p. 251)."

It is difficult for this reader to understand how it can be a "lie (p. 247)" to say that a non-commissioned salesperson has a commission payment of $0 while it is not a lie to say that a non-dog-owner owns zero dogs (p. 251). Designers often treat an object "having zero" as belonging to a different class when it can be very truthfully represented as merely being in a different state of the same class. The situation gets further complicated when special names have arisen for the objects having zero (non-commissioned), for the objects having more than zero (dog-owner), or for both. The same problem occurs with the distinction between objects "having just one" and objects "having more than one" (single-family vs. multi-unit, for example).

Why does RectangleInFrame not inherit from Frame, asks Exercise 2 at the end of Chapter 13? The facile answer, "A rectangle is not a frame (p.344)," implies that software representations should never abbreviate the reality represented in order to realize a cost-saving simplification. Clearly, the case is otherwise. Why, even in the example that is the subject of this exercise we see some important--and justifiable--abbreviation: objects in the Rectangle class are represented with attributes recording their location in a coordinate system, even though location is not strictly speaking an inherent property of a rectangle. There might be circumstances where a shortcut permitting RectangleInFrame to inherit from Frame would be equally justifiable. Questions like this are better answered by describing the trade-off between accuracy of representation and complexity of implementation.

The book raised other minor quibbles and qualms, but mostly it left an abiding respect for the conciseness and the rigor of its design principles. Every software developer should learn them and apply.

Object-orientation is often criticized for lacking a theoretical foundation. While patterns proliferate, principles remain elusive. But the pursuit is on, and Mr. Page-Jones leads the hunt with this fine work.

He catalogs attributes of object-oriented design by which we may intelligently discuss their quality: connascence, encumbrance, cohesion, type conformance, contravariance, covariance, closed behavior, ideal states, ideal behavior, and others. Patterns and anti-patterns are also exhibited, but the distinctive feature is the presentation of principles that all patterns must obey.

Each chapter begins with an overview and ends with a summary followed by exercises with answers. Be sure to read them all. The exercises are interesting, and the "summaries" sometimes (Chapters 5 and 6, for example) introduce new concepts.

The glossary is excellent. The bibliography is unfortunately not annotated. Some passages are over-peppered with footnotes, especially when their point is merely humorous. Overall the footnotes are valuable and the humor is appreciated.

The text takes care to reference backward and forward to related topics, helping readers to trace their own threads.

Some readers want more details about UML. Part II clearly describes a basic subset of UML probably sufficient for 90% of business scenarios, but many of the fine points are omitted.

Part III treats the reader to a series of thought-provoking discussions of the qualities of good software design. Some of the thoughts provoked involve differences of opinion that this reader would like to describe below. Before doing so, however, he must emphasize first just how valuable he found the time spent considering the ideas of Mr. Page-Jones and how strongly he advises others to spend their own time in a like fashion.

This reader was taken aback by the following advice: "Even when designing non-distributed applications, you should try to split a large class (one like Customer . . .) into several 'aspect' classes, using the composition construct to link their objects. For example . . . CustomerFinancials, CustomerShipping, and CustomerProfile. An object of class Customer would contain references to the objects of all three (p. 204)."

There could be in some cases justification for such splitting, but none is offered here. The point of the classes is to represent subjects in the business domain, not to categorize their attributes by their primary use. (And what's the difference between a Customer and a CustomerProfile anyway?)

The composition construct is intended to represent composites from the business perspective, not at the level of the meta-data. While it might be true that the DATA ABOUT the Customer is composed of financial attributes and shipping attributes, it is not true that the Customer ITSELF is a composite of things called "shipping" and "financials." The advice makes the classes model the data about the customer instead of modeling the customer itself.

Another similar pollution of the business perspective occurs in a class diagram showing class ResourceType as aggregate of ResourceInstance, accompanied by the explanation, " . . . all three class diagrams deal with types, each of which aggregates a bunch of instances (p. 391)."

Now, a "type class" always has the potential to be used to define aggregates of the objects of the "instance class." Whether it is in fact so used in a given business depends on the existence of a business operation appropriate for every object of the "type class" and affecting every object of the "instance class". But what operation can we define for class ResourceType equally appropriate for Employees, Rooms, and Whiteboards--and affecting every instance of one of them? Operation PAINT might apply to Rooms, but not to Employees. FIRE to Employees but not to Rooms. Even ERASE would not apply to every Whiteboard simultaneously.

If the business does not have aggregate operations on objects of a type, then the type should not be modeled as an aggregate. Every association having a maximum multiplicity of 1 for one class and * for the other is not an aggregation.

This reader read with great sympathy while Mr. Page-Jones bashed the "know how" cliché of object-oriented design, as in "a document should know how to print itself (p. 250)." In a subsequent footnote, he continues in the same vein: "I find this anthropomorphic view of object orientation to be specious and irrelevant (p. 251)."

It is difficult for this reader to understand how it can be a "lie (p. 247)" to say that a non-commissioned salesperson has a commission payment of $0 while it is not a lie to say that a non-dog-owner owns zero dogs (p. 251). Designers often treat an object "having zero" as belonging to a different class when it can be very truthfully represented as merely being in a different state of the same class. The situation gets further complicated when special names have arisen for the objects having zero (non-commissioned), for the objects having more than zero (dog-owner), or for both. The same problem occurs with the distinction between objects "having just one" and objects "having more than one" (single-family vs. multi-unit, for example).

Why does RectangleInFrame not inherit from Frame, asks Exercise 2 at the end of Chapter 13? The facile answer, "A rectangle is not a frame (p.344)," implies that software representations should never abbreviate the reality represented in order to realize a cost-saving simplification. Clearly, the case is otherwise. Why, even in the example that is the subject of this exercise we see some important--and justifiable--abbreviation: objects in the Rectangle class are represented with attributes recording their location in a coordinate system, even though location is not strictly speaking an inherent property of a rectangle. There might be circumstances where a shortcut permitting RectangleInFrame to inherit from Frame would be equally justifiable. Questions like this are better answered by describing the trade-off between accuracy of representation and complexity of implementation.

The book raised other minor quibbles and qualms, but mostly it left an abiding respect for the conciseness and the rigor of its design principles. Every software developer should learn them and apply.

After going through a lot of books on subjects, this is one I like to return to. It is excellent book on Object Orientation. Books has a load of fun examples that are as paractical as can be in a book. It also has examples of a bad design, errors etc. The UML part is good, but what makes this book different is OO part, I wish that part was longer. You will find out why coupling is bad, why classes should belong to single domain, how to compare different designs, what are the most common errors in inheritance... Highly recomended!

After going through a lot of books on subjects, this is one I like to return to. It is excellent book on Object Orientation. Books has a load of fun examples that are as paractical as can be in a book. It also has examples of a bad design, errors etc. The UML part is good, but what makes this book different is OO part, I wish that part was longer. You will find out why coupling is bad, why classes should belong to single domain, how to compare different designs, what are the most common errors in inheritance... Highly recomended!

One of the things you'll find in it that is not stressed enough in other books about OOD is state management. Programmers often understand basic concepts of how to design objects and what attributes they should have; few are good at taking complex models that involve state transformations (not just talking FSMs) and coming out with a solid design. Now that the middle tier is taking over, people need to realize that the concepts of data integrity, transactional integrity, even simple transformational integrity are part of the requirements of a good object oriented design. This book is one of the few that even addresses the issue.

This book is simply great. Not only the descriptions and explanations are clear, the reader can find many practical examples as well. There is much more to this book then UML, all fundamentals of OO programming and design are explaned in detail. This book is a must-to-have for all OO folks out there, put it on the shelf next to "Design Patterns". By the way, the author also has excellent sense of humor.

Very well written and extremely informative. It's giving me just what I hoped for: Clearly expressed key principles of OO design.

The UML stuff is limited - not good for someone really wanting to learn UML, but great for someone wanting to get started and know the most useful stuff for every day work.

Probably I should have paid more attention at the word "fundamentals" in the title, before buying this book.

The book contains a pretty basic and superficial overview of UML (Part 2), stuffed in the middle of an introduction to OOD/OOP (Part 1), and a description of good OOP principles (Part 3).

Skipping preambles, jokes, and trivial examples, the juicy information about UML can be read through in a couple of hours.

If you are familiar with OOP and you just need a professional tutorial on the UML formalism, you'd better look fo another book.

This is another of Meilir Page-Jones gems. Its enjoyable to read, concise and absolutely trustworthy. Some might find it a little abstract - I just love it. It clearly states what's what in this vague field.

If you want to learn UML as the main goal you should turn to Fowlers landmark book. If you want an alternative turn to Bertrand Meyers "Object oriented software construction". I know it has very, very many pages but its excellent and the second best book around.

Essential reading for anyone who wants to conduct quality object-oriented analysis and design. Thoroughly explains and demonstrates diagrams that can be used as quality deliverables used to make the developers of the object-oriented appliction's job easier. The only thing missing is a comprehensive cased study/complex real world example.

This is a book more about object-oriented design then UML. The first section covers the absolute basics of what OOD is. The middle portion teaches the reader how to use UML to depict their designs. The final section is a set of instructive essays, warning the reader of the problems and pitfalls that often occur in OOD, and how to avoid them.

Page-Jones has an excellent sense of humour, and his engaging style makes this an incredibly enjoyable book to read. You won't even notice that you're actually learning something! I also like the fact that he doesn't use a single programming language for his examples, instead trying to be generic, or alternatively, giving examples from C++, Java, Eiffel, and Smalltalk in turn. This makes the book accessible for all OO designers.

I wouldn't recommend this book to an experienced OO designer who wishes to learn UML. That's not the intended audience. For a new comer, who wishes to learn good design techniques from the start, this is the book for you.

Fundamentals of Object-Oriented Design in UML is a friendly book. I enjoyed it. Meilir Page-Jones maintains a wry sense of humor while threading through the intricacies of OO development in a clear, instructive fashion. The book really does have something for new and experienced programmers alike.

The first two sections of the book are most accessible to those with little programming experience. These sections introduce object orientation and provide a review of the most useful Unified Modeling Language notations while illustrating their use in software design work. But throughout the book the author examines critical principles in such a way that the most experienced software designers will be challenged to reconsider assumptions and habits and to look more critically at their work. The third section of the book is not completely accessible to readers without substantial development experience but even so has enough to offer that it should not be skipped by the newcomer to coding.

In my opinion this book is more about design than UML. If you want an introduction to UML it might make more sense to read Sams Teach Yourself UML in 24 Hours. The introduction to UML in Page-Jones' book is good enough to be your first look at UML but it is not comprehensive and it is oriented to illustrating design principles. This is an excellent book to start with and I would recommend reading it before anything else on UML. And I cannot imagine a better book for introducing object-oriented design. The author has a long track record in structured design and he frequently relates OO to SD concepts. The book is language independent but weighted toward C++. I only speak Java and had a little trouble with the concept of parameterized classes because they don't exist in my frame of reference but this was a very minor problem.

As an experienced programmer looking to develop skills in software design and analysis, I found this book an excellent starting point. The first half of the book discusses the basics of UML, giving both the reasons for a given diagram and several examples each time. The second half discusses design principles - there is little UML used, as it's largely theory, with a few concrete examples of dos and don'ts. I found both sections extremely readable, never patronizing but striking a good balance between a conversational tone and academic rigor.

All in all, I found this book a pleasure to read, and it got me quite excited about UML and OOD. I heartily recommend this as an introduction to the subject.

I am quite familiar to object oriented analysis and design , design patterns, and would like to learn UML, that's the objective I bought this book. I found that this book was very poor to meet my objective. I don't learn UML idioms, something that I really like to. What I really learn from this book is how to draw some UML diagrams.

I think this book assumes that you have minimal or no object oriented analysis, design, and programming. Maybe it is helpful for you if you would like to start to learn OO design. If you would like to apply the UML and design pattern, try Craig Larman Applying UML and Patterns book.

I borrowed this book from a co-worker a couple of weeks ago and I could not put it down. Mr. Page-Jones breaks down the concepts very plainly and succintly with excellent examples.

All the sections were clear and it provides very helpful hints on designing good applications with some real world examples. I really enjoyed his sense of humor and candor throughout the book.

An educational and entertaining book. A must for newbie's to object oriented design

This book is just what I was looking for! I am an experienced programmer, but have not worked in Object Oriented techniques before. This gave me the ability to acquire the new concepts and the new jargon, by showing how they were similiar and evolved from concepts I learned in structured programming and design. (The new ideas did not spring out of nowhere...) This book was not too low (what is a program? a program is...) and not too high (Realization is different from dependency, generalization and association...) but just right.

The major portion of my information technology career of fourteen years has been based in structured design and programming. I've spent the last few years programming in Visual Basic, which is object-based. I've also done a modicum of programming with object-oriented languages (C++ and Java). I jumped into OO programming before taking any design courses (sound familiar?) and eventually felt compelled to remedy the situation by reading a book on OOD. Meilir Page-Jones' book was not a disappointment. I believe that designers and programmers of all experience levels can benefit from reading his book. Newcomers will get the right introduction to OOD while experienced developers will be challenged to reexamine their approach to software construction.

"Fundamentals of Object-Oriented Design" is composed of three parts. In part 1 the author provides an overview of Object-Oriented Design (OOD) by defining key terms and then providing a brief summary of the evolution of software development. This orientation prepares the reader for the rest of the discussions in the book. Part 2 is a summary of the most often used portions of UML syntax. It's not intended to be an exhaustive description. He leaves out those parts of the language that are used infrequently. Part 3 is a compendium of principles of object-oriented design.

The salient benefits of the book are the clear, cogent arguments Mr. Page-Jones articulates in support of the principles he espouses, which are rooted in a very practical approach toward software development. Among other things, you can use most of the principles as bases for code reviews. He also peppers the discussions with entertaining anecdotes, realizing that this heavy stuff needs periodic comic relief. His definitions of OO terminology are concise and he avoids unnecessary abstractions.

I recommend that you add this book to your reference library. There are many zealots for OOD and this book helps to put things in their proper perspective.

Who should read this book: Senior Programmers and Systems Analysts.

This book can be very valuable anyone who builds Object-Oriented computer programs, and anyone building computer programs either is or soon will be using Object-Oriented tools. Although it focuses on the Unified Modeling Language, a standard for most Computer-Aided Software Engineering tools, I found the real value of the book to be in the lucid explanations of principles of good software analysis and design, even more than in the nuts and bolts of UML. Dr. Page-Jones' style continues to combine well-researched information with down-to-earth pragmatism and a delightfully irreverent tone towards those who take this business (or themselves) way too seriously.

Who am I? I am a computational physicist turned systems analyst, with almost 20 years experience developing complex codes for scientific modeling and analysis, now working on real-time defense systems. I have been technical lead and mere contributor, subcontractor and lead contractor. My passion is for tight modular designs that facilitate high-reliablility code.

Part I, Introduction, gives excellent working definitions of the main concepts generally considered part of "Object Orientation" in a way that should be useful even to those beginning to use an OO language, and a historical perspective that helps explain why some issues are still messy.

Part II gets into the "nuts and bolts" of UML itself, of necessity illustrating many key concepts along the way. Even if you never use a CASE tool, the ability to discuss design issues using accepted "standard" diagrams will help you think through the key issues, communicate your ideas more clearly, and ultimately develop better designs. Better designs will not only avoid headaches in the implementation, but also guide the coding effort by making it clearer what the goals are.

Part III, the Principles of Object-Oriented Design, is worth the price of the book all by itself. Meilir's style helps you get through the big words by reminding you that that they are generalizations of common sense. For example, "connaissance" is basically old-fashioned "coupling": the more Module X's correct execution depends on details in Module Y, the more chances for mistakes. The OO quality of "encapsulation" helps you minimize it, whatever you call it. The old-fashioned concept of "coherence" becomes "cohesion": if everything a module does supports a well-understood single purpose, it is less likely there will be confusion or duplication. Do you hate a utility because you need to know so many stupid implementation details to use it properly? Don't lamely whine "I just don't like it!" when you can impress everyone by showing that it has an unjustifiably high "encumbrance."

The book is full of sound principles illustrated with real-world examples. If your gut has ever told you a proposed action was a bad idea, but you didn't know how to express your misgivings, the sound principles in this book will help you put your finger on what is wrong and why. Even if you don't care to use the impressive academic-sounding terms for them, the principles will help you become a more effective, persuasive member of your team. And even if you ARE the whole "team," they will keep you out of trouble.

I must say immediately that OOD is a great weak point in my armoury. I do my designs largely by refactoring as I build from my business level objects. I also re-use the architectural level objects I developed in this way in earlier projects. I still tend to do the UML after I have done the programming, if then.

The book that has helped me a great deal to get things right despite my pragmatic approach is Meilir Page-Jones's recent book "Fundamentals of Object-Oriented Design in UML" (Addison Wesley ISBN 0-201-69946-X).

This book brings up to date Page-Jones earlier book "What Every Programmer Should Know About Object-Oriented Design" (Dorset House ISBN 0-932633-31-5). The biggest differences are that in Fundamentals he uses a subset of UML instead of his own notation, and he has a good chapter on component or interface design.

Both books have lots of examples and exercises, which I hear is a good thing.

The first part of Fundamentals introduces OO. The second part discusses the parts of the UML that are relevant to OOD. He does not discuss Use Cases as being beyond the scope of the book. Instead, he has chapters on Class Diagrams, Object Interaction Diagrams, State Diagrams, and Architecture and Interface Diagrams. The third part of the book is the really useful part. Here Page-Jones discusses good designs and how to achieve them.

I cannot recommend this book too highly.

Written with style, clariity and a sprinkling of humour, this is an excellent introduction to both OO concepts and UML. It is vastly more readible than the competion (e.g. Fowler). and lends itself well to teaching yourself OO/UML. The exercises and answers at the end of each chapter are particularly useful in this respect.

Be warned - it gets tougher as it goes along, but that's because the stuff he's putting across IS tough.

All in all, highly recommended.

The Unified Modeling Language or UML forms a natural relationship with object-oriented programming or OOP. Using the metalanguage, UML, in simultaneous combination with the descriptive language, OOP, is now considered to be the optimal way to build large systems. Furthermore, iterating through several versions is generally conceded to be superior to the previous practice of completing one stage before proceeding to the next. Therefore, it is natural for one to study the two simultaneously, and in an incremental manner. However, that is not an easy task, as the UML is large and OOP is clearly a paradigm shift from previous ways of building software. Page-Jones navigates his way through the myriad complexities of the two very well, doing a superb job of introducing both.
The emphasis is necessarily on the principles of OOP rather than the UML, as that is the true point of the book. It would have been easy to lose that focus, but the UML is reserved for its proper place as the descriptor. All of the basic principles of OOP are presented in a wry style with plenty of humor. The tone was set in the beginning where he makes a bovine metaphor describing the ways one can approach the process of building systems. When it comes time to milk a cow, do we tell the milk to exit the cow or the cow to release the milk? In modeling, both approaches can be considered equally valid until proven otherwise.
Each chapter terminates with a series of problems, where the solutions are verbal or in simple pseudo-code. The solutions are detailed, providing solid reinforcement of the topics. If you are new to OOP or simply need a tune-up, then this book is definitely worth reading. It is quite likely that it will be on my list of top ten books for the year.

This is one of the best introductions to OOD and UML.

If you're learning OOD and/or UML, you should read this book!