четверг, октября 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 коммент.:

Sergey Rozovik комментирует...

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

Alexander Dolgin комментирует...

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

Not a kernel guy комментирует...

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

djdron комментирует...

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

%)

RedChrom комментирует...

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

archimed7592 комментирует...

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

Ornitos комментирует...

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

Алёна комментирует...

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
Это не оффтоп - это спам.
Не, спам я оперативно удаляю. :-)

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

archimed7592 комментирует...

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

Кривоватость заключается в следующем:
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 >();

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

David комментирует...

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

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

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