Слайды 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
Atom feed
10 коммент.:
Все знают как должен выглядеть "правильный" API. К сожалению далеко не у всех получается его сделать :)
Есть, вообще, и видео-версия этого доклада
http://video.google.com/videoplay?docid=-3733345136856180693
Существует три верных способа создать хороший API. К сожалению их никто не знает. :-)
2Alena : "будут поминать исключительно"
%)
Извиняюсь за оффтоп, но вы как-то писали про указатели на функции. Тут http://redchrom.blogspot.com/2007/10/blog-post.html
tсть элегантное решение с mem_funе, да и вообще пост думаю будет интересным )
Это не оффтоп - это спам.
Решение кривоватое, да ещё и по русски писать не умеешь.
Фактически, слайды -- краткое содержание книги Блоха "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
Это не оффтоп - это спам.
Не, спам я оперативно удаляю. :-)
Решение кривоватое
Дык эта, предложи лучше. :-)
Я пока еще не встречала хороших решений этой проблемы..
Дык эта, предложи лучше. :-)
Я пока еще не встречала хороших решений этой проблемы..
Кривоватость заключается в следующем:
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 >();
В общем не нравятся мне такие вот недовелосипеды...
Еще одно "откровение":
http://doc.trolltech.com/qq/qq13-apis.html
и таких много.
Отправить комментарий