1. Chapter 1: Design by Example (in the book Java Design, by Peter Coad & Mark Mayfield)

  2. Chapter 2: Design with Composition, Rather than Inheritance (in the book Java Design, by Peter Coad & Mark Mayfield)

  3. Chapter 3: Design with Interfaces (in the book Java Design, by Peter Coad & Mark Mayfield)

  4. Chapter 4: Design with Threads (in the book Java Design, by Peter Coad & Mark Mayfield)

  5. Chapter 5: Design with Notification (in the book Java Design, by Peter Coad & Mark Mayfield)

  6. "Identify Purpose" Strategy: State the purpose of the system, in 25 words or less. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  7. "Identify Features" Strategy: List the features for setting up, conducting the business, and assessing business results. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  8. "Select Classes" Strategy: Feature-by-feature, look for: role-player, role, transaction (moment or interval), place, container, or catalog-like description. For real-time systems, also look for data acquisition and control devices. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  9. "UI Content" Strategy: Feature-by-feature, establish content: selections, lists, entry fields, display fields, actions, assessments. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  10. "High-Value Scenarios" Strategy: Build scenario views which will exercise each "conducting business" and "assessing results" feature. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  11. "Action Sentence" Strategy: Describe the action in a complete sentence. Put the action in the object (person, place, or thing) which has the "what I know" and "who I know" to get the job done. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  12. "Build an Object Model" Strategy:
    Start with scenario classes and methods.
    Add attributes-content for methods.
    Add attributes-content for the UI.
    Add object connections-message paths for methods.
    Add object connections-look-up paths for the UI.
    (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 1: Design by Example)

  13. "Composition" Strategy: Use composition to extend responsibilities by delegating work to other objects. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 2: Design with Composition, Rather than Inheritance) (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 2: Design with Composition, Rather than Inheritance)

  14. "When to Inherit" Strategy: Inheritance to extend attributes and methods (yet encapsulation is weak within a class hierarchy, so use this mechanism in limited ways).
    Use it when you can satisfy these criteria:
    1. "Is a special kind of," not "is a role played by a"
    2. Never needs to transmute to be an object in some other class
    3. Extends, rather than overrides or nullifies
    4. Does not subclass what is merely a utility class (useful functionality you'd like to reuse)
    (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 2: Design with Composition, Rather than Inheritance)

  15. "Challenge Each Object Connection" Strategy: Is this connection hard-wired to objects in that class (simpler)? Or is this a connection to any object which implements a certain interface (more flexible, extensible, and pluggable)? (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 3: Design with Interfaces)

  16. "Challenge Each Message-Send" Strategy: Is this message-send hard-wired to object in that class (simpler)? Or is this a message-send to any object that implements a certain interface (more flexible, extensible, and pluggable)? (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 3: Design with Interfaces)

  17. "Factor-Out Repeaters" Strategy: Factor-out method signatures that repeat within your object model. Resolve synonyms into a single signature. Generalize overly-specific names into a single signature. Reasons: explicitly capture that commonality; bring a higher level of abstraction into the model. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 3: Design with Interfaces)

  18. "Factor-Out to a Proxy" Strategy: Factor-out method signatures into a proxy, an object with a solo connection to some other object. Reasons: simplifies the proxy within an object model and its scenario views. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 3: Design with Interfaces)

  19. "Factor-Out for Analogous Apps" Strategy: Factor-out method signatures that could be applicable in analogous apps. Reason: increase likelihood of using and reusing off-the-shelf classes. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 3: Design with Interfaces)

  20. "Sync Access to Values" Strategy: When multiple threads compete for values (s) within an object-and you try other thread paths yet design-out such competition-use sync'd methods to limit access (one thread at a time). For multithreaded objects, sync each method that compares, operates on, gets, or sets internal values. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  21. "Zoom In and Sync" Strategy: Zoom in on exactly what you need to sync, factor it out into a separate method, and sync that method. Why: sync for as little time as possible, so other (potentially higher-priority) threads waiting at the start of other sync methods for that object will get to run sooner, rather than later. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  22. "Sync Access to Objects" Strategy: When multiple threads compete for entry into each others sync'd methods-and you try other thread paths yet cannot design-out such competition-use a gatekeeper to control access, one thread at a time; and make sure the objects that the gatekeeper protects have no sync methods. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  23. "Value Gatekeeper" Strategy: Look for a method that increments or decrements a count of a limited resource. Sync that method; give it exclusive access to that count. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  24. "Object Gatekeeper" Strategy: Look for a method that reserves or issues a limited resource, represented by the objects in that collection. Sync that method; give that method exclusive access to that collection of objects. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  25. "Four Thread Designs" Strategy: Apply these thread designs, looking for the simplest one that will satisfy your performance requirements. From simplest to most complex, consider: #1 single thread, #2 prioritized-object threads, #3 prioritized-method threads, #4 prioritized-method prioritized-object threads. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  26. "Prioritized Methods" Strategy: Prioritize your methods. Separate-out cohesive functions with different priorities. Run higher-priority methods in higher-priority threads; run lower-priority methods in lower-priority threads. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  27. "Thread Count" Strategy: Justify the existence of each thread in your design. If you can reduce the thread count and meet response time requirements, do so. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 4: Design with Threads)

  28. "Holder-Interface" Strategy: Establish a collection; define an interface. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 5: Design with Notification)

  29. "Balanced Design" Strategy: Design at one extreme, another extreme, and then somewhere in between. Design connotes looking at alternative and picking a reasonable approach. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 5: Design with Notification)

  30. "Extracting Interfaces from a Class Hierarchy" Strategy: When you find that a subclass is inheriting one or more methods that are merely method signatures, use an interface for those method signatures (that's exactly what an interface is for). (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 5: Design with Notification)

  31. "Don't Limit Your Interfaces with Needless Assumptions" Strategy: Type your interface parameters as a built-in type (for example: int, float, String, StringBuffer, Object). Let each implementer of that interface test for the specific classes of objects it works with. Reason: increase the likelihood of reuse of each interface. (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 5: Design with Notification)

  32. "Message Inward, Notify Outward" Strategy: (in the book Java Design, by Peter Coad & Mark Mayfield - Chapter 5: Design with Notification)

  33. Naming Interfaces The Java convention is to name interfaces using mixed case with the first letter of each word capitalized. The preferred Java convention for the name of an interface is to use a descriptive adjective, such as Runnable or Cloneable, although descriptive nouns, such as Singleton or DataInput, are also common (Gosling, Joy, Steele, 1996).
    amoung the alternatives:
    Prefix the letter 'I' to the interface name.
    Coad and Mayfield     ( 1997) (in the book Java Design, by Peter Coad & Mark Mayfield) suggest appending the letter 'I' to the front of an interface names, resulting in names like ISingleton or IRunnable. This approach helps to distinguish interface names from class and package names. I like this potential naming convention for the simple fact that it makes your class diagrams, sometimes referred to as object models, easier to read. The main disadvantage is that the existing interfaces, such as Runnable, aren't named using this approach, and I don't see them ever changing. Therefore I chose the defacto standard described above.
    (quoted from 6.2 STANDARDS FOR INTERFACES 6.2.1 Naming Interfaces in AmbySoft Inc. Java Coding Standards by Scott W. Ambler, v. July 10, 1997, p. 28)

  34. Documenting Interfaces The following information should appear in the documentation comments immediately preceding the definition of an interface:
    (...) How it should and shouldn't be used. Developers need to know how both how an interface is to be used, as well as how it shouldn't be used (Coad & Mayfield, 1997).(in the book Java Design, by Peter Coad & Mark Mayfield) (...)
    (quoted from 6.2 STANDARDS FOR INTERFACES 6.2.2 Documenting Interfaces in AmbySoft Inc. Java Coding Standards by Scott W. Ambler, v. July 10, 1997, p. 29)