JavaRanch Home    
 
This page:         last edited 24 January 2012         What's Changed?         Edit

OO Patterns UML Refactoring FAQ   

This is the FAQ page for the OO, Patterns, UML and Refactoring forum. Like all other page in this wiki, the page is editable by anyone, so don't hesitate to add useful information.

Contents 



Design Books, UML References 

The book title is linked to the publisher where sample content may reside. The ISBN links to Amazon US which tends to list reviews.

Agile Software Development: Principles, Patterns, and Practices (2002) ISBN 0135974445  Bunkhouse Review

A favorite with forum regulars probably because of its balance. Enough code examples to have you working along but not so much that you will be missing the forest for the trees. UML is only used to model the "interesting bits" and where the code clutter may get in the way of clarity. Primary focus is on object-oriented design principles; patterns come in second - emerging from the OO design principles. An evolution of the author's "Designing Object-Oriented C++ Applications Using the Booch Method" ISBN 0132038374. (See Articles By Robert C. Martin). Received an update as APPP in C#.

UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3e (2003) ISBN 0321193687  Bunkhouse Review (1e)

Fowler distinguishes between three modes of UML : 1. as a sketch 2.as a blueprint 3. as a programming language . Usage as a blueprint tends to be unproductive and usage as a programming language tends to be ineffective, so this title focuses on "UML as a sketch". If you have some serious UML laywering to do then you need to go with the UML Reference Manual.

Refactoring: Improving the Design of Existing Code (1999) ISBN 0201485672  web page Bunkhouse Review

Working Effectively with Legacy Code (2004) ISBN 0131177052  Bunkhouse Review

"To me, legacy code is simply code without (automated) tests." So you've realized that refactoring is useful and essential - however it requires that you have unit tests for the system that you are working on (unless you like working without a safety net). Michael Feathers describes how to approach this problem. Sample code is in Java and C++. Great companion to Refactoring.

Design Patterns: Elements of Reusable Object-Oriented Software (1994) ISBN 0201633612  Bunkhouse Review

The original Gang of Four (GoF - Erich Gamma, Richard Helm, Ralph Johnson, John Vilissides) design patterns book. Code examples are in C++ and diagrams are pre-UML (close enough though). If this is you first foray into design patterns then you may want to start with Head First Design Patterns. To those familiar with design patterns this remains the core design patterns reference. Also available in HTML as the Design Patterns CD ISBN 0201634988.

Patterns of Enterprise Application Architecture (2002) ISBN 0321127420  web page Bunkhouse Review

PoEAA (PEAA)

Domain Driven Design – Tackling Complexity in the Heart of Software (2003) ISBN 0321125215  web page

Your application has finally gotten complex enough to invest the effort into a Domain Model. Do changes to your application always seem to run orthogonal to your current object model? To solve these problems you will have to sit down with your domain experts and formulate a ubiquitous language that forms the base for your new domain object model and will be used for communication among the team and the clients. Then you can move on and create the requisite Entities, Value Objects, Services and Repositories which your software solution will be based on. Eric Evans presents the ideas and concepts that are necessary to create an effective domain model and how to maintain it even in the face of less than perfect collaborating systems. Applying DDD gives a more hands on view (if you don't mind a .NET implementation). The minibook Domain Driven Design Quickly is offered by InfoQ.

Writing Effective Use Cases (2000) ISBN 0201702258  web page

Design Patterns Explained: A New Perspective on Object-Oriented Design, 2e (2004) ISBN 0321247140 

The title of this book needs to be reversed. It's primarily about object-oriented design and shows how design patterns emerge from the systematic application of object-oriented design principles. As far as design patterns go it only discusses the Façade, Adapter, Strategy, Bridge, Abstract Factory, Decorator, Observer, Template Method, Singleton, Object Pool, and Factory Method patterns but in the context of object-oriented design principles. Also notewothy is the inclusion of commonality-variability analysis (from James O. Coplien's Thesis) and the "Analysis Matrix". (Rebecca Wirfs-Brock: Alan Shalloway's Hat Trick)

Object Design: Roles, Responsibilities, and Collaborations (2002) ISBN 0201379430 

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3e (2004) ISBN 0131489062  web page Bunkhouse Review 2e

The third edition departs from its more Big Design Up Front roots and focuses on iterative development; however there still is more documentation being generated here than most Agilists would be comfortable with. Notwithstanding it is a good introduction on OOAD with UML and patterns, though it focuses much more heavily on the non-code/non-executable artifacts (and communication) than APPP does. The quick references printed on the endpapers are extremely useful when you are UML diagramming/sketching.

Head First Design Patterns (2004) ISBN 0596007124  web page Bunkhouse Review

Popular with the Head First crowd. Great for learning about design patterns. The GoF book is still widely used as the core design patterns reference.

Head First Object-Oriented Analysis and Design (2006) ISBN 0596008678  web page

Popular with the Head First crowd.

Refactoring To Patterns (2004) ISBN 0321213351  web page Bunkhouse Review

Refactoring Databases: Evolutionary Database Design (2006) ISBN 0321293533  web page

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (2003) ISBN 0321200683  web page Bunkhouse Review

EAI

Effective Java: Programming Language Guide (2001) ISBN 0201310058  Bunkhouse Review

Itemizes and explains 57 ways to improve your Java code.

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (1998) ISBN 0471197130  web page Bunkhouse Review

Core J2EE Patterns: Best Practices and Design Strategies, 2e (2003) ISBN 0131422464  web page Blueprints Bunkhouse Review

Patterns to deal with problems typical of distributed component architectures and more importantly the idiosyncrasies of J2EE.

J2EE AntiPatterns (2003) ISBN 0131422464  Bunkhouse Review

When working in a distributed component architecture it is important to remember the First Law of Distributed Object Design: Don't distribute your objects (PoEAA p.89). This book explores all the other sins that are so easily committed on the J2EE platform. Good companion to Core J2EE Patterns.

The Unified Modeling Language Reference Manual, 2e (2004) ISBN 0321245628 

If you need to explore some of the dustier corners of UML this is the source to go to. Just don't expect to learn UML from it. Also comes with a handy book-on-CD PDF. For your 20% that you use 80% of the time stick with UML Distilled.

UML for Java™ Programmers (2003) ISBN 0131428489 

Agile Principles, Patterns, and Practices in C# (2006) ISBN 0131857258 

An update to APPP entirely in C# (no Java); also incorporates some of the material from UML for Java™ Programmers (in C#, of course).

Applying Domain-Driven Design and Patterns: With Examples in C# and .NET (2006) ISBN 0321268202 

Object-Oriented Reengineering Patterns (2002) ISBN 1558606394  web page

Object-Oriented Design Heuristics (1996) ISBN 020163385X 

A collection of OO design heuristics that was already collected in the age of C++. Published shortly after the GoF book.

Information Modeling and Relational Databases: from Conceptual Analysis To Logical Design (2001) ISBN 1558606726  Home

The book on Object Role Modeling. Can be a bit frustrating as some terms are used before they are defined and are nowhere to be found in the glossary. See ORM.

OoDesignBooks GoodBooksOnUml


Design 

OoDesignFaq


Design Patterns 

Before diving into design patterns make sure that you know and understand the Object-Oriented Design Principles. Always Apply Patterns Gently. Realize that you may be experiencing Gregg Irwin's ten stages of design pattern adoption:

  1. You use it without being aware that you're using it
  2. You hear about it, read up on it, and tinker a bit
  3. You learn more and start using it explicitly, if naïvely
  4. You get the fire and evangelize (optional)
  5. Something "clicks"
  6. You learn more and apply it "less naïvely" and more implicitly
  7. Time passes and you see flaws
  8. You question the concept (often because you misapplied it)
  9. You either forget about it or add knowledge and experience (Repeat steps 5–9 as necessary)
  10. You use it without being aware that you're using it
From: A Head Start on Domain-Driven Design Patterns
Design patterns make communication more effective. Using design pattern monikers prevents getting bogged down in the discussion of minutiae, provided all parties are equally versed in the design patterns referenced.
We allow inner complexity of language because it enables us to shift that complexity away from the individual utterance.
(p. xlv, The Ruby Way, 2e ISBN 0672328844).

WhenToApplyDesignPatterns DesignPatternFaq DesignPatternLinks DesignPatterns


Refactoring 

UML 

AssociationVsAggregationVsComposition


UML Tools 

If you are using UML as a sketch then most simple UML tools will do. If you want to generate code from UML - well, you may want to reconsider. It is probably going to take longer than to simply code the thing. All of the excruciating detail that you have to supply will only serve to obfuscate your essential design. Model-Driven Development: One Curmudgeon's View - Why won't the general purpose language be graphical?

It was simply faster to write code…Computers don't do big picture.
If you are trying to reverse engineer a blueprint from existing code then be prepared to toss the generated artifact after you have developed an initial understanding of the system. It will usually take intervention from a human being to re-organize and re-interpret the diagrams, to strip away the trivial to only leave the essential, in order to attain any degree of clarity. Usually simpler is better. For example the built-in UML capability of Visio Studio Professional 2002 bogs you down with pointless micro-management of the entire model. With Pavel Hruby's "Visio Stencil and Templates" you can simply focus on what needs to be communicated.

Use Cases 

Primers on text-based use cases by Alistair Cockburn:

UML for Java™ Programmers Chapter 5: Use Cases :

Use Cases Diagrams Of all the diagrams in UML, use case diagrams are the most confusing, and the least useful. With the exception of the System Boundary Diagram, which I’ll describe in a minute, I recommend that you avoid them entirely. ... Use Case Relationships Use case relationships fall into the category of things that “seemed like a good idea at the time”. I suggest that you actively ignore them. They’ll add no value to your use cases, or to your understanding of the system, and they will be the source of many never ending debates about whether or not to use «extends» or «generalization».


ORM 

Not Object Relational Mapping but Object Role Modeling. In fact the Object in ORM has little to do with the Object from object-orientation. ORM consists of a 7 step Conceptual Schema Design Procedure (CSDP) which leads to a logical model that can then be algorithmically transformed into a design described by an entity relationship or UML diagram. The CSDP hasn't really caught on. However Joe Celko made an interesting observation in his book Data & Databases: Concepts in Practice ISBN 1558604324 p.23:

The main proponent of ORM is Terry Halpin, and I recommend getting his book for details of the method. What I do not recommend is using the diagrams in his method. In addition to diagrams, his method includes the use of simplified English sentences to express relationships. These formal sentences can then be processed and used to generate schemas in a mechanical way. Most of the sentences are structured as subject-verb-object, but the important thing is that the objects are assigned are role in the sentence. For example, the fact that "Joe Celko wrote Data and Databases for Morgan Kaufman Publishers" can be amended to read 'AUTHOR: Joe Celko wrote BOOK: 'Data and Databases' for PUBLISHER: Morgan Kaufman," which gives us a higher level, more abstract sentence...with the implication that there are many authors, books and publishers involved. Broadly speaking, objects and entities become the subjects and objects of the sentences, relationships become verbs, and the constraints become prepositional phrases.

In essence the first step of the CSDP can be used as a valuable method during the initial stages of data design even if you don't go with the full-blown CSDP. This step is described in the sample chapter of Halpin's book. Also users tend to be more comfortable with these word based designs - they don't require them to learn yet another notation (Technical diagrams (ORM, ER, UML) don't make much sense to non-technical domain experts).



CategoryFaq CategoryUml

JavaRanchContact us — Copyright © 1998-2014 Paul Wheaton