Как спроектировать хороший API и почему это так важно
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Как спроектировать хороший API и почему это так важно

  • 3,433 views
Uploaded on

Перевод презентации "How to Design a Good API and Why it Matters" Joshua Bloch

Перевод презентации "How to Design a Good API and Why it Matters" Joshua Bloch

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,433
On Slideshare
3,430
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
35
Comments
0
Likes
4

Embeds 3

http://www.slideshare.net 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Third bullet: As if that’s not enough pressure.. Hopefully I’ve convinced you that API design is important. But why is it important to you personally?
  • If you get it right, it looks obvious in retrospect. It’s a good sign if people say: “of course that’s how it should look; so what?” Appropriate to audience: a good API in C++ might be a bad API in Java; a good API for economists might be a bad API for physicists.
  • So now you know the characteristics of a good API. In the remainder of the talk I’ll outline the general principles that lead to good APIs and specific attributes of Class, Method, and Exception APIs that lead to goodness. Finally I’ll conclude with a couple of quick examples API refactorings. First two sections are a bit fluffy but the last four are chock-full of code examples
  • Mention “subtle color code”
  • Худшее, что Вы можете сделать, это провести 6 месяцев над написанием 248-страничной спецификации прежде чем показать ее кому либо. К этому моменту Вы не сможете отказаться от API даже если принципиально ошибочно.
  • A static utility class containing decorators for applying retry policies, and static factories for the retry policies themselves. This one-page description isn’t yet a true specification, but it’s good enough to evaluate and improve the API. So how do you evaluate it?
  • You write code to it, early and often! Examples are among the most important code you’ll ever write to an API. They form the basis of thousands of actual programs so any good practices are magnified a thousand-fold, and and bugs pop up in a thousand places.
  • It’s best if different people write the plug-ins. The you test SPI doc as well.
  • I don’t mean that you shold take one API component from everyone and throw them together into a rude semblance of an API; that’s a recipe for disaster. Rather, you should come up with a unified, coherent design that represents a compromise among all the stakeholders in the API. You generally can’t fix API mistakes outright, but you improve things by making judicious, compatible additions
  • That’s all I have to say about the process of API design, now onto the principles of what makes for a good API design.
  • Often these names are metaphorical in nature, e.g. Publish-Subscribe service. (Some of these ‘bad’ names cross the line into ugly.)
  • If you remember only one thing in the talk, this is it. Conceptual weight, sometimes called conceptual surface-area
  • Не всегда легко понять, что входит в детали реализации. Хороший настраиваемый параметр : размер пула очередей ; плохой : Число элементов в хэш-таблице.
  • This advice is somewhat controversial, and is less applicable in a research setting
  • Parnas said it better than I ever could, so I’m simply going to read you what he said: I don’t know about you , but I find that inspiring. I’ve got religion. <next slide> and the only thing to do about it is to document religiously.
  • There is no excuse for an undocumented API element – period
  •  (Next slide contains Dimentsion ex.)
  • Here’s an example from Java’s awt
  • That’s the last general principal I’m going to talk about.
  • Now let’s see how all of this applies to class design
  • This idea is central to functional programming
  • In plain English, ask yourself “is every Foo a Bar”? Unless you can say yes *with a straight face*, Foo must not extend Bar.
  • That’s all I have to say about class design
  • Now on to method design
  • Here’s and example from the W3C DOM API
  • Here’s a particularly egregious example of what not to do
  • I believe that method overloading is overused
  • Mention that Builder pattern is a special case of breaking up the method Nasty example from Win32 API
  • The get method on ByteBuffer in Java’s nio package violates this advice ThreadGroup.enumerate returns void
  • In a language that has checked and unchecked exceptions, …. A checked exception represents a strong statement by the API designer that a method can fail in some way, and the programmer should consider this and attempt to take corrective action. If you can’t take corrective action, then it shouldn’t be a checked exception.
  • Two quick API refactorings
  • This is an example where you win by solving a general problem
  • Around 1996 many people wrote thread-local variable implementations in Java. Most of them looked like this:
  • Code to assign a serial number to each thread and print a thread’s serial number Notice that outer class class is noninstantiable, and each of its static methods takes a single instance of the inner class. So why don’t we move the set and get methods onto the inner class? Once we do that there are no methods left on the outer class except the getKey static factory. So why don’t we do away with the outer class entirely? This is what we’re left with:
  • This is essentially the ThreadLocal API that Java adopted in release 1.2 Notice that it’s trivial to generify this API. It was impossible to generify the first API, and difficult to generify the second.
  • Not a glory profession - API designers like plumbers. Your APIs won’t be perfect, but with a bit of luck they’ll be good
  • An homage to Jon Bentley’s “Bumper-sticker Computer Science” in “More Programming Pearls” iJava Best-Practices book with a hidden agenda of encouraging programmers to think about API design **** Timothy Boudreau Jaroslav Tulach: Designing APIs that Stand the Test of Time Thursday 10/26, 3:30 P.M.

Transcript

  • 1. Как спроектировать хороший API и почему это так важно Joshua Bloch перевод coxx
  • 2. Почему проектирование API так важно ?
    • API могут быть мощными активами компании
      • Клиенты вкладывают значительные средства в покупку , программирование , обучение
      • Стоимость прекращения использования API может быть слишком высока
      • Успешные публичные API «подсаживают» клиентов
    • Также могут быть серьезным грузом для компании
      • Плохой API может привести к бесконечному потоку звонков в службу поддержки
      • Может препятствовать движению вперед
    • Публичный API – навсегда. Есть только один шанс сделать все правильно.
  • 3. Почему проектирование API важно для Вас ?
    • Если Вы программируете – Вы уже проектировщик API
      • Хороший код – модульный. Каждый модуль имеет свой API.
    • Полезные модули, как правило, используются повторно
      • Как только у модуля появляются пользователи , нельзя изменить его API по своему желанию
      • Хорошие повторно используемые модули – это активы компании
    • Мышление в терминах API повышает качество кода
  • 4. Характеристики хорошего API
    • Легко изучать
    • Легко использовать , даже без документации documentation
    • Трудно использовать неправильно
    • Легко читать и поддерживать код, который использует его
    • Достаточно мощный чтобы удовлетворять требованиям
    • Легко развивать
    • Соответствует аудитории
  • 5. Оглавление
    • I. Процесс проектирования API
    • II. Основные принципы
    • III. Проектирование классов
    • IV. Проектирование методов
    • V. Проектирование исключений
    • VI. Рефакторинг API
  • 6.
    • I. Процесс проектирования API
  • 7. Соберите требования – со здоровой долей скептицизма
    • Зачастую вам будут предлагать готовые решения (вместо требований)
      • Могут существовать лучшие решения
    • Ваша задача извлечь истинные требования
      • Должны быть в форме use-cases
    • Может быть проще и полезнее решить более общую задачу
    • Что они говорят : “ Нам нужны новые структуры данных и RPC с атрибутами версии 2 ”
    • Что они подразумевают : “ Нам нужен новый формат данных, который бы позволил развивать набор атрибутов ”
  • 8. Начните с краткой спецификации. Одна страница – это идеально.
    • На этом этапе гибкость предпочтительнее завершенности
    • Разошлите спецификацию стольким людям, скольким это возможно.
      • Прислушайтесь к их отзывам и примите это со всей серьезностью
    • Если Ваша спецификация будет краткой , её легче будет изменять
    • Начинайте воплощать, когда обретете уверенность
      • Здесь обязательно предполагается кодирование
  • 9. Sample Early API Draft (1)
    • // A strategy for retrying computation in the face of failure.
    • public interface RetryPolicy {
    • // Called after computation throws exception
    • boolean isFailureRecoverable (Exception e);
    • // Called after isFailureRecoverable returns true.
    • // Returns next delay in ns, or negative if no more retries.
    • long nextDelay (long startTime, int numPreviousRetries);
    • }
  • 10. Sample Early API Draft (2)
    • public class RetryPolicies {
    • // Retrying decorators (wrappers)
    • public static ExecutorService retryingExecutorService (
    • ExecutorService es, RetryPolicy policy);
    • public static Executor retryingExecutor (
    • Executor e, RetryPolicy policy);
    • public static <T> Callable<T> retryingCallable (
    • Callable<T> computation, RetryPolicy policy);
    • public static Runnable retryingRunnable (
    • Runnable computation, RetryPolicy policy);
    • // Delay before nth retry is random number between 0 and 2^n
    • public static RetryPolicy exponentialBackoff (
    • long initialDelay, TimeUnit initialDelayUnit,
    • long timeout, TimeUnit timeoutUnit,
    • Class<? extends Exception>... recoverableExceptions);
    • public static RetryPolicy fixedDelay (long delay,
    • TimeUnit delayUnit, long timeout, TimeUnit timeoutUnit,
    • Class<? extends Exception>... recoverableExceptions);
    • }
  • 11. Описывайте ваш API как можно раньше и чаще
    • Начинайте прежде чем Вы реализовали API
      • Это убережет Вас от создания от реализации, которую Вы потом выбросите
    • Начинайте даже раньше , чем написали правильные спецификации
      • Это убережет Вас от написания спецификаций, которые Вы потом выбросите
    • Продолжайте описывать API по ходу воплощения
      • Это убережет Вас от неприятных сюрпризов непосредственно перед развертыванием
    • Код продолжает жить в примерах и модульных тестах
      • Это наиболее важный код, который Вы когда-либо писали
      • Формируется основа для Design Fragments [Fairbanks, Garlan, & Scherlis, OOPSLA ‘06, P. 75]
  • 12. Описание SPI – еще важнее
    • Service Provider Interface (SPI)
      • Интерфейс плагинов позволяет использовать множество реализаций
      • Пример : Java Cryptography Extension (JCE)
    • Напишите несколько плагинов до релиза
      • Если один , он скорее всего не будет совместим с другими
      • Если два , возможны проблемы с совместимостью
      • Если три , все будет работать, как надо
    • Will Tracz называет это “ Правило трех ” ( Confessions of a Used Program Salesman , Addison-Wesley, 1995)
    Плохо Хорошо
  • 13. Сохраняйте реалистичные ожидания
    • Большинство проектировщиков API перегружены ограничениями
      • Вы не можете угодить всем
      • Старайтесь нравиться всем в равной степени
    • Ожидайте, что совершите ошибки
      • Несколько лет использования в реальном мире выявят их
      • Ожидайте, что будете развивать API
  • 14.
    • II. Основные принципы
  • 15. API должен делать что-нибудь одно и делать это хорошо
    • Функционал должно быть легко объясним
      • Если трудно придумать название – это, как правило, плохой знак
      • Хорошие наименования являются движущей силой
      • С другой стороны , хорошие имена означают, что вы на верном пути
    • Хорошо : Font, Set, PrivateKey, Lock, ThreadFactory, TimeUnit, Future
    • Плохо : DynAnyFactoryOperations, _BindingIteratorImplBase, ENCODING_CDR_ENCAPS, OMGVMCID
  • 16. API должен быть минимальным, но не меньше
    • API должен удовлетворять требованиям
    • Когда сомневаетесь – оставьте в покое
      • Функционал , классы, методы, параметры и т.д.
      • Вы всегда можете добавить , но Вы не сможете убавить
    • Концептуальная полнота важнее объема
    • Ищите оптимальное соотношение возможностей и полноты ( power-to-weight ratio)
  • 17. Реализация не должна влиять на API
    • Детали реализации
      • Путают пользователей
      • Ограничивают свободу для изменения реализации
    • Поймите что такое «детали реализации»
      • Не определяйте явно поведение методов
      • Например : не определяйте хэш-функции
      • Все настраиваемые параметры – под подозрением
    • Не давайте деталям реализации “ утекать ” в API
      • Например: форматы хранения на диске и форматы передачи по сети, исключения
  • 18. Минимизируйте доступность ВСЕГО
    • Делайте классы и их члены максимально скрытыми
    • Публичные классы не должны иметь публичных полей ( за исключением констант )
    • Максимизируйте сокрытие информации [Parnas]
    • Минимизируйте связи
      • Это позволяет понимать, использовать, собирать, тестировать, отлаживать и оптимизировать модули независимо
  • 19. Имена имеют значение – API это маленький язык
    • Названия должны быть самоочевидными
      • Избегайте загадочных сокращений
    • Стремитесь к согласованности
      • Одно и то же слово должно означать одну и ту же вещь по всему API
      • ( а в идеале, по всем API на платформе)
    • Будьте последовательны – стремитесь к гармонии
    • Если Вы сделали все правильно , код читается как проза
    • if (car.speed() > 2 * SPEED_LIMIT)
    • speaker.generateAlert(&quot;Watch out for cops!&quot;);
  • 20. Документация имеет значение
    • Повторное использование – это нечто, что гораздо проще сказать, чем сделать . Чтобы достичь этого требуется не только хороший дизайн, но и очень хорошая документация . Даже когда мы видим хороший дизайн , что бывает не часто , мы не увидим повторно используемых компонентов без хорошей документации .
    • - D. L. Parnas, Software Aging. Proceedings of the 16th International Conference on Software Engineering, 1994
  • 21. Документируйте скрупулёзно ( document religiously )
    • Документируйте каждый класс , интерфейс , метод , конструктор , параметр и исключение
      • Класс : что представляет собой экземпляр
      • Метод : контракт между методом и его клиентом
        • Входные условия ( preconditions), выходные условия ( postconditions ) , побочные эффекты
      • Параметр : укажите единицы измерения , формат , права доступа владельца
    • Очень внимательно документируйте пространство состояний
    • Нет оправдания недокументированным элементам API . Точка!
  • 22. Учитывайте, как принимаемые решения влияют на производительность
    • Плохие решения могут ограничить производительность
      • Использование изменяемых ( mutable ) типов
      • Использование конструктора вместо статической фабрики ( static factory )
      • Использование типов реализации вместо интерфейсных типов
    • Не делайте специальных оберток API (do not warp) для увеличения производительности
      • Проблема с производительностью, лежащая в основе будет исправлена , но головная боль останется с вами навсегда
      • Хороший дизайн обычно сопровождается хорошей производительностью
  • 23. Влияние решений по проектированию API на производительность реальна и постоянна
    • Component.getSize() возвращает Dimension
    • Dimension – изменяемый тип ( mutable )
    • Каждый вызов getSize вынужден создавать Dimension
    • Это приводит к миллионам бесполезных созданий объектов
    • Альтернативный метод добавлен в 1.2 , но старый клиентский код остается медленным
    • (пример взят из Java AWT)
  • 24. API должен мирно сосуществовать с платформой
    • Делайте то, что принято (в платформе)
      • Положитесь на стандартные методы именования
      • Избегайте устаревших параметров и возвращаемых типов
      • Подражайте шаблонам в базовом API платформы и языка
      • Используйте с выгодой полезные для API особенности ( API-friendly features) : generics, varargs, enums, аргументы по умолчанию
    • Знайте и избегайте ловушки и западни API
      • Finalizers, public static final arrays
    • Не используйте транслитерацию в API
  • 25.
    • III. Проектирование классов
  • 26. Минимизируйте изменяемость ( mutability)
    • Классы должны быть неизменяемы ( immutable ) пока не появится достаточной причины сделать обратное
      • Плюсы : простота , thread-safe, легкость повторного использования
      • Минусы : отдельные объекты для каждого значения
    • Если класс изменяемый , сохраняйте пространство состояний маленьким и четко определенным
      • Проясните, когда какой метод допустимо вызывать
    • Bad: Date , Calendar
    • Good: TimerTask
  • 27. Наследуйте классы только там где это имеет смысл
    • Наследование подразумевает взаимозаменяемость
      • Используйте наследование только если существует отношение « is-a » ( is every Foo a Bar? )
      • В противном случае используйте композицию
    • Публичные классы не должны наследовать другие публичные классы для удобства реализации
    • Плохо : Properties extends Hashtable Stack extends Vector
    • Хорошо : Set extends Collection
  • 28. Проектируйте и документируйте с учетом возможного наследования или запретите его
    • Наследование нарушает инкапсуляцию (Snyder, ‘86)
      • Подклассы чувствительны к деталям реализации суперкласса
    • Если вы разрешаете наследование , документируйте само-использование(?) ( self-use )
      • Как методы используют друг друга ?
    • Консервативная политика : все конкретные классы – final .
    • Плохо : Множество конкретных классов в библиотеках J2SE
    • Хорошо : AbstractSet , AbstractMap
  • 29.
    • IV. Проектирование методов
  • 30. Не заставляйте клиента делать то, что может сделать модуль
    • Уменьшайте необходимость использования шаблонного кода
      • Обычно делается через copy-and-paste
      • Уродливый, раздражающий и предрасположенный к ошибкам
    • import org.w3c.dom.*;
    • import java.io.*;
    • import javax.xml.transform.*;
    • import javax.xml.transform.dom.*;
    • import javax.xml.transform.stream.*;
    • // DOM code to write an XML document to a specified output stream.
    • static final void writeDoc(Document doc, OutputStream out)throws IOException{
    • try {
    • Transformer t = TransformerFactory.newInstance().newTransformer();
    • t.setOutputProperty(OutputKeys.DOCTYPE_SYSTEM, doc.getDoctype().getSystemId());
    • t.transform(new DOMSource(doc), new StreamResult(out));
    • } catch(TransformerException e) {
    • throw new AssertionError(e); // Can’t happen!
    • }
    • }
  • 31. Не нарушайте принцип «наименьшего изумления»
    • Пользователь API не должен удивляться поведению
      • Это стоит дополнительных усилий при реализации
      • Это стоит даже снижения производительности
    • public class Thread implements Runnable {
    • // Проверяет, была ли нить прервана .
    • // Очищает статус interrupted у данной нити .
    • public static boolean interrupted();
    • }
    • Вот особенно вопиющий пример того, чего не стоит делать.
  • 32. Падай быстро – сообщайте об ошибках как можно скорее
    • Лучше всего во время компиляции – статическая типизация, generics .
    • В время выполнения – лучше всего первый вызов ошибочного метода.
      • Метод должен быть failure-atomic
    • // A Properties instance maps strings to strings
    • public class Properties extends Hashtable {
    • public Object put( Object key, Object value);
    • // Throws ClassCastException if this properties
    • // contains any keys or values that are not strings
    • public void save(OutputStream out, String comments);
    • }
  • 33. Предоставьте программный доступ ко всем данным, доступным в виде строк
    • В противном случае клиентам придется анализировать строки
      • Мучительно для клиентов
      • Хуже того , это де-факто превращает формат строк в часть API
    • public class Throwable {
    • public void printStackTrace(PrintStream s);
    • public StackTraceElement[] getStackTrace(); // Since 1.4
    • }
    • public final class StackTraceElement {
    • public String getFileName();
    • public int getLineNumber();
    • public String getClassName();
    • public String getMethodName();
    • public boolean isNativeMethod();
    • }
  • 34. Используйте перегрузку методов с осторожностью ( Overload With Care )
    • Избегайте неоднозначных перегрузок
      • Multiple overloadings applicable to same actuals
      • Консервативный подход : нет двух (методов или функций) с одним и тем же числом аргументов
    • Просто «потому что Вы можете» не означает, что «Вы должны»
      • Часто лучше просто использовать другое имя
    • Если Вам необходимо сделать неоднозначные перегрузки , обеспечьте одинаковое поведение для одинаковых аргументов
    • public TreeSet(Collection c); // Ignores order
    • public TreeSet(SortedSet s); // Respects order
  • 35. Используйте подходящие типы параметров и возвращаемых значений
    • Отдавайте предпочтение интерфейсным типам перед классами для входных параметров
      • Обеспечивает гибкость и улучшает производительность
    • Используйте наиболее конкретный тип для аргументов
      • Перемещает ошибки с времени выполнения на время компиляции
    • Не используйте строки если существует лучший тип
      • Строки громоздки , медленны и часто приводят к ошибкам
    • Не используйте плавающую точку для денежных значений
      • Двоичная плавающая точка приводит к неточным результатам !
    • Используйте double (64 бита ) вместо float (32 бита )
      • Потеря точности существенна , потеря производительности незначительна
  • 36. Используйте один и тот же порядок параметров во всех методах
    • Особенно важно если типы параметров одинаковы
    • #include <string.h>
    • char *strncpy(char * dst , char * src , size_t n);
    • void bcopy (void * src , void * dst , size_t n);
    • java.util.Collections – первый параметр всегда коллекция которая будет изменена или к которой делается запрос
    • java.util.concurrent – время всегда задается как long delay, TimeUnit unit
  • 37. Избегайте длинных списков параметров
    • Три или меньше параметров – это идеально
      • Сделайте больше и пользователю придется смотреть в документацию
    • Длинные списки параметров с одинаковыми типами – вредны
      • Программисты по ошибке сдвигают параметры
      • Программа продолжает собираться, запускаться, но работает неверно !
    • Техники сокращения списка параметров
      • Разбейте метод на части
      • Создайте вспомогательный класс, содержащий параметры
    • // Одинадцать параметров включая четыре последовательных int
    • HWND CreateWindow(LPCTSTR lpClassName, LPCTSTR lpWindowName,
    • DWORD dwStyle, int x, int y, int nWidth, int nHeight,
    • HWND hWndParent, HMENU hMenu, HINSTANCE hInstance,
    • LPVOID lpParam);
  • 38. Избегайте возвращать значения которые требуют особой обработки
    • Возвращайте массив нулевой длины или пустое множество , а не null
    • package java.awt.image;
    • public interface BufferedImageOp {
    • // Returns the rendering hints for this operation,
    • // or null if no hints have been set.
    • public RenderingHints getRenderingHints();
    • }
  • 39.
    • V. Проектирование исключений
  • 40. Выбрасывайте исключения только чтобы сигнализировать об исключительной ситуации
    • Не заставляйте клиента использовать исключения для управления потоком выполнения
    • private byte[] a = new byte[BUF_SIZE];
    • void processBuffer (ByteBuffer buf) {
    • try {
    • while (true) {
    • buf.get(a);
    • processBytes(tmp, BUF_SIZE);
    • }
    • } catch (BufferUnderflowException e) {
    • int remaining = buf.remaining();
    • buf.get(a, 0, remaining);
    • processBytes(bufArray, remaining);
    • }
    • }
    • С другой стороны , не «падайте» молча
    • ThreadGroup.enumerate(Thread[] list)
  • 41. Отдавайте предпочтение Unchecked Exceptions
    • Checked – клиент должен предпринять меры по устранению
    • Unchecked – программная ошибка
    • Чрезмерное использование checked exceptions приводит к шаблонному ( copy-paste) программированию
    • try {
    • Foo f = (Foo) super.clone();
    • ....
    • } catch (CloneNotSupportedException e) {
    • // This can't happen, since we’re Cloneable
    • throw new AssertionError();
    • }
  • 42. Включайте Failure-Capture информацию в исключения
    • Предоставляет возможность для диагностики и восстановления
    • Для unchecked exceptions достаточно сообщения
    • Для checked exceptions предоставьте акцессор (метод, получающий текущее значение свойства)
  • 43.
    • VI. Рефакторинг API
  • 44. 1. Списковые операции над Vector -ом
    • public class Vector {
    • public int indexOf(Object elem, int index);
    • public int lastIndexOf(Object elem, int index);
    • ...
    • }
    • Не очень мощно – поддерживается только поиск
    • Трудно использовать без документации
  • 45. Sublist операции после рефакторинга
    • public interface List {
    • List subList(int fromIndex, int toIndex);
    • ...
    • }
    • Чрезвычайно мощно – поддерживаются все операции
    • Использование интерфейса уменьшает концептуальный вес
      • Высокое отношение мощность - вес
    • Легко использовать без документации
  • 46. 2. Thread-Local переменные ( Thread-Local Variables )
    • // Broken - inappropriate use of String as capability.
    • // Keys constitute a shared global namespace.
    • public class ThreadLocal {
    • private ThreadLocal() { } // Non-instantiable
    • // Sets current thread’s value for named variable.
    • public static void set( String key , Object value);
    • // Returns current thread’s value for named variable.
    • public static Object get( String key );
    • }
  • 47. Thread-Local Variables Refactored (1)
    • public class ThreadLocal {
    • private ThreadLocal() { } // Noninstantiable
    • public static class Key { Key() { } }
    • // Generates a unique, unforgeable key
    • public static Key getKey() { return new Key(); }
    • public static void set( Key key , Object value);
    • public static Object get( Key key );
    • }
    • Работает , но требует использования шаблонного кода
    • static ThreadLocal.Key serialNumberKey = ThreadLocal.getKey();
    • ThreadLocal.set(serialNumberKey, nextSerialNumber());
    • System.out.println(ThreadLocal.get(serialNumberKey));
  • 48. Thread-Local Variables Refactored (2)
    • public class ThreadLocal<T> {
    • public ThreadLocal() { }
    • public void set(T value);
    • public T get();
    • }
    • Устраняет беспорядок в API и клиентском коде
    • static ThreadLocal<Integer> serialNumber = new ThreadLocal<Integer>();
    • serialNumber.set(nextSerialNumber());
    • System.out.println(serialNumber.get());
  • 49. Заключение
    • Проектирование API – это благородное и полезное дело
      • Развивает программистов, конечных пользователей, компании
    • Это выступление охватывает некоторые хитрости этого ремесла
      • Не будьте их рабами , но ...
      • не нарушайте их без особой на то причины
    • Проектировать API трудно
      • Это занятие не для одного человека
      • Совершенство недостижимо , но Вы все равно попробуйте
  • 50. Shameless Self-Promotion “ Bumper-Sticker API Design” - P. 506 in OOPSLA ‘06 Program
  • 51. Как спроектировать хороший API и почему это так важно Joshua Bloch