четверг, октября 11, 2007

Слайды How to Design a Good API and Why it Matters

Слайды How to Design a Good API and Why it Matters помогут сдизайнить API за который вас будут поминать исключительно добрым словом.

Кусок оттуда:

Characteristics of a Good API
  • Easy to learn
  • Easy to use, even without documentation
  • Hard to misuse
  • Easy to read and maintain code that uses it
  • Sufficiently powerful to satisfy requirements
  • Easy to extend
  • Appropriate to audience
в

10 комментариев:

  1. Sergey Rozovik11/10/07 22:58

    Все знают как должен выглядеть "правильный" API. К сожалению далеко не у всех получается его сделать :)

    ОтветитьУдалить
  2. Unknown11/10/07 23:49

    Есть, вообще, и видео-версия этого доклада
    http://video.google.com/videoplay?docid=-3733345136856180693

    ОтветитьУдалить
  3. Анонимный12/10/07 00:06

    Существует три верных способа создать хороший API. К сожалению их никто не знает. :-)

    ОтветитьУдалить
  4. Анонимный13/10/07 13:21

    2Alena : "будут поминать исключительно"

    %)

    ОтветитьУдалить
  5. Анонимный13/10/07 14:18

    Извиняюсь за оффтоп, но вы как-то писали про указатели на функции. Тут http://redchrom.blogspot.com/2007/10/blog-post.html
    tсть элегантное решение с mem_funе, да и вообще пост думаю будет интересным )

    ОтветитьУдалить
  6. archimed759213/10/07 20:14

    Это не оффтоп - это спам.
    Решение кривоватое, да ещё и по русски писать не умеешь.

    ОтветитьУдалить
  7. Анонимный14/10/07 01:06

    Фактически, слайды -- краткое содержание книги Блоха "Effective Java". Когда издавалась эта книга, он ещё в Sun работал. Неужели опыт работы в google не дал товарищу Блоху нового материала на тему правильного API...

    ОтветитьУдалить
  8. Alena14/10/07 01:49

    2Sergey Rozovik
    Все знают как должен выглядеть "правильный" API. К сожалению далеко не у всех получается его сделать :)

    2Not a kernel guy
    Существует три верных способа создать хороший API. К сожалению их никто не знает. :-)

    Хех, я понимаю ваш сарказм :-).
    Тем не менее это не повод не пытаться...

    2djdron
    2Alena : "будут поминать исключительно"

    Я в хорошем смысле этого слова! :-)

    ПОМИНАТЬ несов. перех. и неперех.
    1. разг. Вспоминать. // Упоминать о ком-л., чем-л.

    2RedChrom
    вы как-то писали про указатели на функции.
    Да, было дело.
    Тут http://redchrom.blogspot.com/2007/10/blog-post.html
    tсть элегантное решение с mem_funе, да и вообще пост думаю будет интересным )

    Интересно, спасибо.

    2archimed7592
    Это не оффтоп - это спам.
    Не, спам я оперативно удаляю. :-)

    Решение кривоватое
    Дык эта, предложи лучше. :-)
    Я пока еще не встречала хороших решений этой проблемы..

    ОтветитьУдалить
  9. archimed759215/10/07 17:00

    Дык эта, предложи лучше. :-)
    Я пока еще не встречала хороших решений этой проблемы..
    Кривоватость заключается в следующем:
    1. Зачем нужен vConstructor/Constructor? Лично я не собираюсь для каждой фабрики писать такие helper-классы и использую уже давно изобретённый "велосипед" boost::function как универсальный функтор. Если фабрика не абстрактная, то метод регистрации делают шаблонным чтобы ещё больше сделать код обобщённым.
    2. В вышеуказанной "статье" предлагается руками регистрировать классы в фабрике - тоже плохо. Это должно происходить на этапе статической инициализации.
    По хорошему класс должен регистрироваться так:
    template class MyFactory::RegisterProduct< ProductA1 >;
    template class MyFactory::RegisterProduct< ProductB1 >;

    Если уж очень нужно регистрировать разные наборы продуктов, то так:
    MyFactory::instance().register< ProductA2 >();
    MyFactory::instance().register< ProductB2 >();

    В общем не нравятся мне такие вот недовелосипеды...

    ОтветитьУдалить
  10. dao19/10/07 19:26

    Еще одно "откровение":

    http://doc.trolltech.com/qq/qq13-apis.html

    и таких много.

    ОтветитьУдалить