Pre-prepared links to this document
(updated August 2, 1997)
Online ressources
(added August 2, 1997)
Erratas (for printed book)
marc.meurrens@acm.org
(
http://homepages.ulb.ac.be/~meurrens)
http://www.oi.com/newbook.htm
Peter Coad
(coad@oi.com) &
Mark Mayfield
(mlm@jencon.com)
http://www.prenhall.com/allbooks/ptr_0132711494.html, from http://www.amazon.com where you may access reader's comments and order the book, and from the presentation published by Peter Coad him self (including large excerpts but without the images).
http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/index.html
[back]
Java Design by Peter Coad and Mark Mayfield.
|
You'll find here miscellaneous data gathered from
the official book homepage (provided by the publishers) at URL http://www.prenhall.com/allbooks/ptr_0132711494.html, from http://www.amazon.com where you may access reader's comments and order the book, and from the presentation published by Peter Coad him self (including large excerpts but without the images).
An online beta version (without pictures) is available on Peter Coad's book page and mirrored here.
File
 coad-ppt.zip (172 kb --> 2,5 Mb , 43 slides) is a mirror of the
PowerPoint presentation (slides) you may consider usefull. This (new)
presentation available on the site of Peter Coad (http://www.oi.com) is a step forward into JDK 1.1 as it adds "event source/listener" and "property change
source/support/listener."
Indeed, the current book's version was written with JDK 1.0.2. in mind. To understand the additional OO capabilities of JDK 1.1 stay tuned! ;-) (we already know that Peter Coad is producing an upgrade) |
A list of approx. 32 "pre-prepared" links to this page
is available at URL http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/coad-LinksTo.html. ( updated August 6, 1997)
These links are (or will be) used in other pages related to "OO design and Coding Standards".
mlm@jencon.com),
list of erratas for printed book, better table of contents, better feedback form.
|
|
Java Design : Building Better Apps and Applets (Yourdon Press Computing Series) by Peter Coad
(coad@oi.com) and
Mark Mayfield
(mlm@jencon.com)
Bk&Cd-r*NR Edition
|
The official book homepage (provided by the publishers) is at URL http://www.prenhall.com/allbooks/ptr_0132711494.html
and is quite poor.
You'll find much more details (including reader's comments),
and may order the book, at URL http://www.amazon.com. Select "search by author, title, subject"; fill the form with author = "Coad, Peter" and title = "Java Design".
Or, read the presentation published by Peter Coad him self.
"Understand Java as a serious client/server development language. In this book, internationally-respected object oriented development experts Peter Coad and Mark Mayfield show programmers the best way to design Java client/server applications and applets that are as efficient and reliable as possible. The book covers object models and scenario views as they apply to Java programming. It introduces threads and concurrency, and shows how to design software that makes the most effective, reliable use of multithreading. Developers will learn better ways to think about Java exceptions -- and when and how to use them. The book also covers Java's implementation of notification. Java: Designing Better Apps and Applets will be invaluable to any professional software developer interested in client/server programming with Java.
Synopsis
This book discusses real applications for Java, not just how do I make my Web site prettier. It discusses strategic issues associated with Client/Server development projects and identifies projects where Java would be an ideal language to use. The book is heavily illustrated with a full case study throughout the book."
(updated August 2, 1997)
While you are waiting the printed version ordered 3 weeks ago (!), consider the beta version of the book (without pictures), available on the site of Peter Coad http://www.oi.com (Object International, Inc.) or here.
Our colleague
yves.callewaert@ficsgrp.com (
BeJUG voting member) reports: "the book is not really readable in that format (without picture)
but it can help to have an idea of what is inside.".
File
coad-ppt.zip (172 kb --> 2,5 Mb , 43 slides) is a mirror of the PowerPoint presentation you may also consider usefull. This new presentation available on the site of Peter Coad is a step forward into JDK 1.1 as it includes 4 new
charts at the end, adding in "event source/listener" and "property change
source/support/listener."
Unfortunalely, the book is based on JDK 1.0.2 and, thus, not on "inner classes", "beans", etc.
All Javaneers and OO designers expect thus with interest the next version of Coad's work.
We already know Peter Coad is working on it!
As a first step into JDK 1.1,
the new PowerPoint Presentation slides now includes "event source/listener" and "property change
source/support/listener."
Stay tuned on our joodcs (Java OO Design & Coding Standards) site: we may expect
a *second* book (not a
second edition, but rather, a second book) on java design, specifically
focussing on distributed bean apps...
If you want to receive notifications of updates of this page, fill the small form below.
Peter Coad's latest book, written with Mark Mayfield is JAVA DESIGN: Building Better Apps and Applets. ISBN 0-13-271149-4
"Just finished devouring JAVA Design and I loved
it! I think it is one of those books that will influence
my thinking for years to come. (and there have only been
a few other books like it in my experience)." John
Pinto, Director of R&D, Precision Programming, Inc.
pintoj@mail.idt.net
Check out the following excerpts:
Introduction Chapter 1: Design by ExampleChapter 2: Design with
Composition, Rather than InheritanceChapter 3: Design with Interfaces
Chapter 4: Design with ThreadsChapter 5: Design with
Notification(added August 2, 1997)
We publish a list of erratas (for the printed book) which is a REVISITED mirror of
the list of corrections
to the first printing of JAVA DESIGN:
Building Better Apps and Applets
Introduction
Chapter 1: Design by ExampleIn this chapter, you've worked with scenario views and objects models for a business application (for Charlie's Charters) and a real-time system (for Zoe's Zones).
Along the way, you've learned and applied scenario-view notation (showing a time-ordered sequence of object interactions) and object-model notations (showing the responsibilities of each class of objects and each object within that class).
You've worked with these specific strategies for designing better apps:
"Identify Purpose" Strategy: State the purpose of the system, in 25 words or less.
"Identify Features" Strategy: List the features for setting up, conducting the business, and assessing business results.
"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.
"UI Content" Strategy: Feature-by-feature, establish content: selections, lists, entry fields, display fields, actions, assessments.
"High-Value Scenarios" Strategy: Build scenario views which will exercise each "conducting business" and "assessing results" feature.
"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.
"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.
Chapter 2: Design with
Composition, Rather than InheritanceIn this chapter, we've explored two mechanisms for extending a design: composition and inheritance.
Inheritance is useful in limited contexts. Composition is useful in nearly every context.
Inheritance was all the rage in the early days of object-oriented development. Yet over time, designers have discovered that inheritance is effective only within certain contexts.
Indeed, composition, in tandem with interfaces (Chapter 3), is
far more common, for more generally useful, and much closer to
the heart of good object-oriented design.
Here are the strategies that you've learned and applied in this chapter:
"Composition" Strategy: Use composition to extend responsibilities by delegating work to other objects.
"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)
Chapter 3: Design with Interfaces
In this chapter, you've worked with interfaces, common sets of method signatures that you define for use again and again in your application.
Designing with interfaces is the most significant aspect of Java-inspired design: freedom from object connections that are hardwired to just one class of objects, freedom from scenario interactions that are hardwired to just one class of objects. For systems in which flexibility, extensibility, and pluggability are key issues, Java-style interfaces are a must. Indeed, the larger the system, and the longer the potential life span of a system, the more significant interface-centric scenario development becomes.
In this chapter, you've learned and applied these specific strategies for designing better apps:
"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)?
"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)?
"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.
"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.
"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.
Chapter 4: Design with ThreadsIn this chapter, you've worked with threads, streams of program execution.
For an application to run, you must have at least one thread.
Why bother with multiple threads?
Most designs must account for multiple streams of program execution; this chapter shows how to do that, safely.
Multiple threads let you give the appearance of doing more than one thing at a time. For example, your application can serve multiple clients at the same time.
Threads also give you the clean, simple way to design-in the main thing you want your application to do, along with other things that you'd like it to be aware of or check on from time-to-time.
The strategies you learned and applied in this chapter are:
"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.
"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.
"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.
"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.
"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.
"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.
"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.
"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.
Chapter 5: Design with
NotificationIn this chapter, you've worked with notification, how lets other objects know that something significant has happened.
Passive notification is simple yet resource-intensive. Timer-based notification is a useful pattern. Active notification is most interesting; it's an essential ingredient for problem-domain object reuse; it's an essential ingredient for designing loosely-coupled subsystems.
Together, we explored three major notification mechanisms:
The strategies you learned and applied in this chapter are:
"Holder-Interface" Strategy: Establish a collection; define an interface.
"Balanced Design" Strategy: Design at one extreme, another extreme, and then somewhere in between. Design connotes looking at alternative and picking a reasonable approach.
"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).
"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.
"Message Inward, Notify Outward" Strategy:
UI-invoked changes: message inward, from UI to PD.
PD-invoked changes: notify outward, from PD to UI.
|
Brussels, last modified:
published by marc.meurrens@acm.org
(http://homepages.ulb.ac.be/~meurrens)
original URL: http://www.oi.com/newbook.htm
current URL: http://www.ulb.ac.be/esp/ip-Links/Java/joodcs/PeterCoad.html
internet programming Links: http://www.ulb.ac.be/esp/ip-Links (ip-Links)
Université Libre de Bruxelles: http://www.ulb.ac.be (ULB)
La Cambre - Architecture: http://www.lacambre-archi.be
Belgian JAVA User Group: http://www.bejug.org (BeJUG)
|
|
Use this form to send your feedback and/or submit a link
|
Conventions used in these pages:
html file,  text file or  java or CPP source located on our site
 download area (on our site) or file to be downloaded (use the right button of your mouse)
document on a belgian academic or scientific site
document (on another site) or  link to be fixed or  link we didn't visit/evaluate; documents indicated with their full URL will be displayed in their own "top" window.
 ftp download or
 file to be downloaded (use the right button of your mouse)
indicates a "mailto" link.
and indicate links added or updated within the last month.
Click on the separator to reach a higher level in the page or site hierarchy.
| |
|
