Tulach Practical API Design

Confessions of a Java Framework Architect
1. ed
ISBN: 978-1-4302-0974-4
Verlag: Apress
Format: PDF
Kopierschutz: 1 - PDF Watermark

E-Book, Englisch, 387 Seiten

You might think more than enough design books exist in the programming world already. In fact, there are so many that it makes sense to ask why you would read yet another. Is there really a need for yet another design book? In fact, there is a greater need than ever before, and Practical API Design: Confessions of a Java Framework Architect fills that need! Teaches you how to write an API that will stand the test of time Written by the designer of the NetBeans API at Sun Technologies Based on best practices, scalability, and API design patterns

Jaroslav Tulach is the founder and initial architect of NetBeans, later acquired by Sun Technologies. As creator of the technology behind NetBeans, he is still with the project to find ways to improve the design skills among all the programmers who contribute to the success of NetBeans open source project.

Autoren/Hrsg.

Tulach, Jaroslav

Inhaltsverzeichnis

1;Contents at a Glance;4
2;Contents;6
3;About the Author;12
4;Acknowledgments;13
5;Prologue: Yet Another Design Book?;14
5.1;API Design Is Different;15
5.2;Who Should Read This Book?;18
5.3;Is This Book Useful Only for Java?;19
5.4;Learning to Write APIs;22
5.5;Is This Book Really a Notebook?;23
6;Theory and Justification;25
6.1;The Art of Building Modern Software;29
6.1.1;Rationalism, Empiricism, and Cluelessness;29
6.1.2;Evolution of Software So Far;31
6.1.3;Gigantic Building Blocks;33
6.1.4;Beauty, Truth, and Elegance;34
6.1.5;More Cluelessness!;36
6.2;The Motivation to Create an API;39
6.2.1;Distributed Development;39
6.2.2;Modularizing Applications;41
6.2.3;It’s All About Communication;46
6.2.4;Empirical Programming;47
6.2.5;The First Version Is Always Easy;49
6.3;Determining What Makes a Good API;51
6.3.1;Method and Field Signatures;51
6.3.2;Files and Their Content;52
6.3.3;Environment Variables and Command-Line Options;53
6.3.4;Text Messages As APIs;55
6.3.5;Protocols;56
6.3.6;Behavior;58
6.3.7;I18N Support and L10N Messages;59
6.3.8;Wide Definition of APIs;60
6.3.9;How to Check the Quality of an API;60
6.4;Ever-Changing Targets;65
6.4.1;The First Version Is Never Perfect;65
6.4.2;Backward Compatibility;66
6.4.3;The Importance of Being Use Case Oriented;75
6.4.4;API Reviews;78
6.4.5;Life Cycle of an API;79
6.4.6;Incremental Improvements;83
7;Practical Design;88
7.1;Do Not Expose More Than You Want;91
7.1.1;A Method Is Better Than a Field;92
7.1.2;A Factory Is Better Than a Constructor;93
7.1.3;Make Everything Final;95
7.1.4;Do Not Put Setters Where They Do Not Belong;96
7.1.5;Allow Access Only from Friend Code;97
7.1.6;Give the Creator of an Object More Rights;101
7.1.7;Do Not Expose Deep Hierarchies;105
7.2;Code Against Interfaces, Not Implementations;108
7.2.1;Removing a Method or a Field;109
7.2.2;Removing or Adding a Class or an Interface;110
7.2.3;Inserting an Interface or a Class into an Existing Hierarchy;110
7.2.4;Adding a Method or a Field;111
7.2.5;Comparing Java Interfaces and Classes;112
7.2.6;In Weakness Lies Strength;113
7.2.7;A Method Addition Lover’s Heaven;114
7.2.8;Are Abstract Classes Useful?;116
7.2.9;Getting Ready for Growing Parameters;117
7.2.10;Interfaces vs. Classes;119
7.3;Use Modular Architecture;120
7.3.1;Types of Modular Design;122
7.3.2;Intercomponent Lookup and Communication;125
7.3.3;Writing an Extension Point;138
7.3.4;The Need for Cyclic Dependencies;139
7.3.5;Lookup Is Everywhere;143
7.3.6;Overuse of Lookup;147
7.4;Separate APIs for Clients and Providers;151
7.4.1;Expressing API/SPI in C and Java;151
7.4.2;API Evolution Is Different from SPI Evolution;153
7.4.3;Writer Evolution Between Java 1.4 and 1.5;154
7.4.4;Split Your API Reasonably;165
7.5;Keep Testability in Mind;169
7.5.1;API and Testing;170
7.5.2;The Fade of the Specification;172
7.5.3;Good Tools Make Any API Easier;174
7.5.4;Test Compatibility Kit;176
7.6;Cooperating with Other APIs;179
7.6.1;Beware of Using Other APIs;179
7.6.2;Leaking Abstractions;183
7.6.3;Enforcing Consistency of APIs;184
7.6.4;Delegation and Composition;188
7.6.5;Prevent Misuses of the API;196
7.6.6;Do Not Overuse the JavaBeans Listener Pattern;200
7.7;Runtime Aspects of APIs;204
7.7.1;Fixing Odyssey;206
7.7.2;Reliability and Cluelessness;209
7.7.3;Synchronization and Deadlocks;211
7.7.4;Preparing for Reentrant Calls;234
7.7.5;Memory Management;237
7.8;Declarative Programming;243
7.8.1;Make Objects Immutable;245
7.8.2;Immutable Behavior;249
7.8.3;Compatibility of Documents;250
8;Daily Life;254
8.1;Extreme Advice Considered Harmful;256
8.1.1;An API Must Be Beautiful;257
8.1.2;An API Has to Be Correct;258
8.1.3;An API Has to Be Simple;259
8.1.4;An API Has to Have Good Performance;261
8.1.5;An API Must Be 100 Percent Compatible;262
8.1.6;An API Needs to Be Symmetrical;265
8.2;Paradoxes of API Design;266
8.2.1;API Doublethink;267
8.2.2;The Invisible Job;270
8.2.3;Overcoming the Fear of Committing to a Stable API;271
8.2.4;Minimizing Maintenance Cost;274
8.3;Evolving the API Universe;277
8.3.1;Resuscitating Broken Libraries;278
8.3.2;Conscious vs. Unconscious Upgrades;284
8.3.3;Alternative Behavior;288
8.3.4;Bridges and the Coexistence of Similar APIs;293
8.4;Teamwork;306
8.4.1;Organizing Reviews Before Committing Code;306
8.4.2;Convincing Developers to Document Their API;309
8.4.3;Big Brother Never Sleeps;311
8.4.4;Accepting API Patches;315
8.5;Using Games to Improve API Design Skills;318
8.5.1;Overview;318
8.5.2;Day 1;319
8.5.3;Day 2;332
8.5.4;Day 3: Judgment Day;340
8.5.5;Play Too!;347
8.6;Extensible Visitor Pattern Case Study;348
8.6.1;Abstract Class;351
8.6.2;Preparing for Evolution;353
8.6.3;Default Traversal;355
8.6.4;Clean Definition of a Version;357
8.6.5;Nonmonotonic Evolution;359
8.6.6;Data Structure Using Interfaces;360
8.6.7;Client and Provider Visitors;361
8.6.8;Triple Dispatch;364
8.6.9;A Happy End for Visitors;366
8.6.10;Syntactic Sugar;366
8.7;End-of-Life Procedures;369
8.7.1;The Importance of a Specification Version;370
8.7.2;The Importance of Module Dependencies;370
8.7.3;Should Removed Pieces Lie Around Forever?;373
8.7.4;Splitting Monolithic APIs;374
9;The Future;377
9.1;Principia Informatica;378
9.2;Cluelessness Is Here to Stay;379
9.3;API Design Methodology;380
9.4;Languages Ready for Evolution;382
9.5;The Role of Education;384
9.6;Share!;386
10;Bibliography;387
11;Index;388