logo资料库

《软件框架设计的艺术》(Practical API Design)【英文原版PDF】.pdf

第1页 / 共417页
第2页 / 共417页
第3页 / 共417页
第4页 / 共417页
第5页 / 共417页
第6页 / 共417页
第7页 / 共417页
第8页 / 共417页
资料共417页,剩余部分请下载后查看
Practical API Design: Confessions of a Java Framework Architect
Contents at a Glance
Contents
About the Author
Acknowledgments
Prologue: Yet Another Design Book?
API Design Is Different
Who Should Read This Book?
Is This Book Useful Only for Java?
Learning to Write APIs
Is This Book Really a Notebook?
Theory and Justification
The Art of Building Modern Software
Rationalism, Empiricism, and Cluelessness
Evolution of Software So Far
Gigantic Building Blocks
Beauty, Truth, and Elegance
More Cluelessness!
The Motivation to Create an API
Distributed Development
Modularizing Applications
Nonlinear Versioning
It’s All About Communication
Empirical Programming
The First Version Is Always Easy
Determining What Makes a Good API
Method and Field Signatures
Files and Their Content
Environment Variables and Command-Line Options
Text Messages As APIs
Protocols
Behavior
I18N Support and L10N Messages
Wide Definition of APIs
How to Check the Quality of an API
Comprehensibility
Consistency
Discoverability
Simple Tasks Should Be Easy
Preservation of Investment
Ever-Changing Targets
The First Version Is Never Perfect
Backward Compatibility
Source Compatibility
Binary Compatibility
Functional Compatibility—the Amoeba Effect
The Importance of Being Use Case Oriented
API Reviews
Life Cycle of an API
Incremental Improvements
Do Not Expose More Than You Want
A Method Is Better Than a Field
A Factory Is Better Than a Constructor
Make Everything Final
Do Not Put Setters Where They Do Not Belong
Allow Access Only from Friend Code
Give the Creator of an Object More Rights
Do Not Expose Deep Hierarchies
Code Against Interfaces, Not Implementations
Removing a Method or a Field
Removing or Adding a Class or an Interface
Inserting an Interface or a Class into an Existing Hierarchy
Adding a Method or a Field
Comparing Java Interfaces and Classes
In Weakness Lies Strength
A Method Addition Lover’s Heaven
Are Abstract Classes Useful?
Getting Ready for Growing Parameters
Interfaces vs. Classes
Use Modular Architecture
Types of Modular Design
Intercomponent Lookup and Communication
Writing an Extension Point
The Need for Cyclic Dependencies
Lookup Is Everywhere
Overuse of Lookup
Separate APIs for Clients and Providers
Expressing API/SPI in C and Java
API Evolution Is Different from SPI Evolution
Writer Evolution Between Java 1.4 and 1.5
Split Your API Reasonably
Keep Testability in Mind
API and Testing
The Fade of the Specification
Good Tools Make Any API Easier
Test Compatibility Kit
Cooperating with Other APIs
Beware of Using Other APIs
Leaking Abstractions
Enforcing Consistency of APIs
Delegation and Composition
Prevent Misuses of the API
Do Not Overuse the JavaBeans Listener Pattern
Runtime Aspects of APIs
Fixing Odyssey
Reliability and Cluelessness
Synchronization and Deadlocks
Document the Threading Model
Pitfalls of Java Monitors
Deadlock Conditions
Deadlock Test
Testing Race Conditions
Analyzing Random Failures
Advanced Usage of Logging
Execution Flow Control Using Logging
Preparing for Reentrant Calls
Memory Management
Declarative Programming
Make Objects Immutable
Immutable Behavior
Compatibility of Documents
Extreme Advice Considered Harmful
An API Must Be Beautiful
An API Has to Be Correct
An API Has to Be Simple
An API Has to Have Good Performance
An API Must Be 100 Percent Compatible
An API Needs to Be Symmetrical
Paradoxes of API Design
API Doublethink
The Invisible Job
Overcoming the Fear of Committing to a Stable API
Minimizing Maintenance Cost
Evolving the API Universe
Resuscitating Broken Libraries
Conscious vs. Unconscious Upgrades
Alternative Behavior
Bridges and the Coexistence of Similar APIs
Teamwork
Organizing Reviews Before Committing Code
Convincing Developers to Document Their API
Big Brother Never Sleeps
Accepting API Patches
Using Games to Improve API Design Skills
Overview
Day 1
Problem of Nonpublic API Classes
The Immutability Problem
The Problem of the Missing Implementation
The Problem of Possibly Incorrect Results
Solutions for Day 1
Day 2
I Want to Fix My Mistakes Problem
Solutions for Day 2
Day 3: Judgment Day
Conclusions
What Was Wrong with subclassingsolution and stackbasedsolution?
What Was Wrong with inputandoperation?
What Was Wrong with alwayscreatenewcircuit and welltestedsolution?
What Was Wrong with elementbasedsolution?
Play Too!
Extensible Visitor Pattern Case Study
Abstract Class
Preparing for Evolution
Default Traversal
Clean Definition of a Version
Nonmonotonic Evolution
Data Structure Using Interfaces
Client and Provider Visitors
Triple Dispatch
A Happy End for Visitors
Syntactic Sugar
End-of-Life Procedures
The Importance of a Specification Version
The Importance of Module Dependencies
Should Removed Pieces Lie Around Forever?
Splitting Monolithic APIs
The Future
Principia Informatica
Cluelessness Is Here to Stay
API Design Methodology
Languages Ready for Evolution
The Role of Education
Share!
Bibliography
Index
cyan MagenTa yellOW Black PanTOne 123 c BOOks fOR PROfessIOnals By PROfessIOnals® The eXPeRT’s VOIce® In JaVa™ TechnOlOgy Practical API Design: Confessions of a Java™ Framework Architect Dear Reader, Maybe you’re standing in a bookstore, holding this book in your hand, and ask- ing yourself, “Should I buy it?” Here is your answer. If you’ve ever written code and handed it to others to let them compile their code against yours, then you’re ready to enter the API design world and this book will help you explore it. However, this book doesn’t attempt to “teach API design in five easy lessons.” It cannot be read in “only three days!” If you’re looking for a quick handbook, this book is probably not for you. On the other hand, if you’re interested in a deeper knowledge of API design, in knowing not only the how, but also the why, let me introduce myself to you before you put this book back on the shelf. My name is Jaroslav Tulach and I am the founder and initial architect of the NetBeans™ project, which is not just a well-known IDE, but also the first modu- lar desktop application framework written in the Java™ language. This book is based on notes that I’ve collected over the last ten years, while designing and maintaining NetBeans APIs and transferring this knowledge to the rest of our developers. It’s a journal from the heart of the NetBeans laboratory, describing our problems, our growing understanding of them, the solutions we’ve chosen, and the conclusions we made after applying them. Although our knowledge has been gathered while working on NetBeans, it’s general enough to be useful for most software projects. Knowledge of proper API design is essential for the successful creation of 21st century software. Let this book be your guide while exploring the big wide world of API design. Companion eBook Available P r a c t i c a l A P I D e s i g n Practical API Design Confessions of a Java™ Framework Architect API design done right, from one of the Java™ community’s most experienced API designers. Jaroslav Tulach RelATeD TITleS Companion eBook See last page for details on $10 eBook version SOURCE CODE ONLINE www.apress.com Shelve in Software Development User level: Intermediate–Advanced ISBN 978-1-4302-0973-7 9 0 0 0 0 l T u a c h Jaroslav Tulach Founder of the NetBeans™ Platform 9 781430 209737 this print for content only—size & color not accurate 7" x 9-1/4" / CASEBOUND / MALLOY (0.8125 INCH BULK -- 416 pages -- 50# Thor)
0973-7 FM.qxd 6/26/08 11:25 AM Page i Practical API Design Confessions of a Java Framework Architect Jaroslav Tulach
0973-7 FM.qxd 6/26/08 11:25 AM Page ii Practical API Design: Confessions of a Java Framework Architect Copyright © 2008 by Jaroslav Tulach All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13: 978-1-4302-0973-7 ISBN-13 (electronic): 978-1-4302-0974-4 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Java™ and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc., in the US and other countries. Apress, Inc., is not affiliated with Sun Microsystems, Inc., and this book was writ- ten without endorsement from Sun Microsystems, Inc. Lead Editor: Clay Andres Editorial Board: Clay Andres, Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Matthew Moodie, Joseph Ottinger, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Kylie Johnston Copy Editor: Susannah Davidson Pfalzer Associate Production Director: Kari Brooks-Copony Production Editor: Ellie Fountain Compositor: Gina Rexrode Proofreader: Liz Welch Indexer: Broccoli Information Management Artist: Kinetic Publishing Services, LLC Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail orders-ny@springer-sbm.com, or visit http://www.springeronline.com. For information on translations, please contact Apress directly at 2855 Telegraph Avenue, Suite 600, Berkeley, CA 94705. Phone 510-549-5930, fax 510-549-5939, e-mail info@apress.com, or visit http://www.apress.com. Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Special Bulk Sales–eBook Licensing web page at http://www.apress.com/info/bulksales. The information in this book is distributed on an “as is” basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work. The source code for this book is available to readers at http://www.apress.com.
0973-7 FM.qxd 6/26/08 11:25 AM Page iii
0973-7 FM.qxd 6/26/08 11:25 AM Page iv Contents at a Glance About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Prologue: Yet Another Design Book? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii PART 1 Theory and Justification ICHAPTER 1 ICHAPTER 2 ICHAPTER 3 ICHAPTER 4 The Art of Building Modern Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 The Motivation to Create an API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Determining What Makes a Good API . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Ever-Changing Targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 PART 2 Practical Design ICHAPTER 5 Do Not Expose More Than You Want. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 ICHAPTER 6 Code Against Interfaces, Not Implementations . . . . . . . . . . . . . . . . . . 87 ICHAPTER 7 Use Modular Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 ICHAPTER 8 Separate APIs for Clients and Providers . . . . . . . . . . . . . . . . . . . . . . . 131 ICHAPTER 9 Keep Testability in Mind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 ICHAPTER 10 Cooperating with Other APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 ICHAPTER 11 Runtime Aspects of APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 ICHAPTER 12 Declarative Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 PART 3 Daily Life ICHAPTER 13 Extreme Advice Considered Harmful . . . . . . . . . . . . . . . . . . . . . . . . . . 239 ICHAPTER 14 Paradoxes of API Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 ICHAPTER 15 Evolving the API Universe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261 ICHAPTER 16 Teamwork. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 ICHAPTER 17 Using Games to Improve API Design Skills . . . . . . . . . . . . . . . . . . . . . 303 ICHAPTER 18 Extensible Visitor Pattern Case Study. . . . . . . . . . . . . . . . . . . . . . . . . . 333 ICHAPTER 19 End-of-Life Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 iv
0973-7 FM.qxd 6/26/08 11:25 AM Page v IEPILOGUE The Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 IBIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 IINDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375 v
0973-7 FM.qxd 6/26/08 11:25 AM Page vi
分享到:
收藏