Да-да-да. Говнокода не существует, есть «творческий подход». Это когда сначала натворил, а потом думаешь: «И с помощью какого нечистого духа все это работает?» :D
Developer Lab у нас проводился 05.12.2013 в формате Developer Lab + Хакатон — день Lab, потом два дня Хакатон. Использовалась последняя на тот момент SDK, версию точно не помню. За два дня Хакатона запустить все нормально не удалось, а потом я на это забил. Честно говоря, так как js не очень люблю, решил дождаться Tizen 3 в надежде на Qt. Но впечатление от разработки этой связки осталось негативное, не дело это — когда пользователь должен такую базовую вещь подолгу отлаживать и вылизывать. Я предполагал, что это будет попроще — например, я определяю декларативно форматы сообщений, а SDK за меня генерирует нужный набор классов.
Клиент VK Для Tizen написан как гибридное приложение. И работает.
Сразу вспомнился анекдот про программистов.
Пациент приходит к программисту-хирургу:
— Доктор, у меня нога болит.
Доктор смотрит внимательно на свою и говорит:
— Странно, у меня такая же, но не болит.
Я проблему уже описывал представителям samsung, там же на Developer Lab. Если вкратце — писался клиент к демону mpd, взаимодействие с демоном писалось как сервис на С++ (использовали клиентскую библиотеку), а интерфейс на html. За основу был взят пример из SDK, только переписаны форматы сообщений между нативной и веб частями. После этого нативное приложение начало падать при передаче команды из веб части в нативную. Отладчик ничего вразумительного не показывал, присутствовавшие специалисты samsung в один голос утверждали, что код вроде бы правильный, и непонятно, почему не работает. В общем, у меня сложилось впечатление, что связка С++ и html крайне неудобная и сырая.
Я пробовал программировать под Tizen 2.1 в рамках Tizen Developer Lab в Нижнем Новгороде. Логика на js — это медленно, а взаимодействие js и С++ — это печально.
Совершенно с Вами согласен. И хочу добавить свою копеечку — очень хочется возможность использования библиотеки Qt. На Nokia N900 в свое время неплохо пошла, мне довелось поковыряться.
серьёзные уязвимости типа Heartbleed побудили разработчиков, исследователей и простых пользователей к повышенно внимательному изучению надежности этих продуктов.
Будем надеяться, что сейчас наковыряют уязвимостей по-максимуму и пофиксят, потом поспокойнее станет. Все-таки лучше знать, что уязвимость была, но исправлена, чем вообще о ней не знать.
В данном контексте это обсуждать бессмысленно — вот когда будут конкретные задачи с конкретным бюджетом, тогда и надо будет думать, применять этот метод или нет. А я Вам привел вполне работоспособный пример решения поставленной Вами проблемы:
А если результат — это единичный экземпляр класса?
Намного проще считать, что функция всегда оперирует валидным объектом.
Проще — не значит правильнее. Вы подсовываете пользователю общие исключения, я предпочитаю предоставлять ему более подробную информацию. Что лучше в использовании в конечном счете — решает сам пользователь.
Не вижу особой проблемы написать по одной строчке подобного текста на функцию. Обработку ошибок все равно делать надо, причем чем подробнее, тем лучше.
Лучше тем, что можно выбрасывать более понятные исключения. Если брать пример с сотрудником: программист вызывает метод fire() у Null Object и получает в ответ не стандартное исключение «TypeError: Cannot read property 'fire' of null» (как, например, в javascript), а Ваше, где более человеческим языком написано «попытка удаления несуществующего сотрудника», ну или что-то подобное.
Ну я бы сделал так, чтобы ошибку выдавал сам объект, но Вам почему-то этот вариант не нравится.
Если Вы хотите пример — поясню:
Класс Object пишется таким образом, что если объект является невалидным (Null Object), то при попытке доступа к данным этого объекта либо выбрасывается исключение, если Вы используете исключения, либо выдаются такие же null объекты, если Вы исключения не используете. При этом принцип подстановки Лисков не нарушается, хотя бы потому, что тип вообще один и не имеет подтипов.
Null Object выдаст ошибку там, где это будет нужно. И если Вы забудете ее сгенерировать в нужной ситуации, то это будет исключительно Ваша ошибка как разработчика API, а не как не пользователя, который это API использует. А детали реализации
result.id
надо от пользователя скрывать (это называется инкапсуляция), чтобы он не имел прямой доступ к полям класса, а использовал соответствующие методы.
А какая вообще разница между nullptr и null object в этом случае? И тот и другой либо будут как-то обработаны, либо приведут к появлению ошибок или исключений. И если в рамках реализации API Вы еще можете влиять на этот процесс, то за ее пределами Вы уже ничего не сделаете.
Это же публичный API, пользователи могут использовать возвращенные им объекты, как им угодно.
Именно поэтому и надо сделать сериализацию за пользователя. Если он вдруг захочет сделать свою, ему никто не помешает накосячить там как угодно. Но по крайней мере одна работающая реализация от разработчика API будет.
защитить от неразумного разработчика его же программу — весьма сложно
Что случится, если кто-то передаст в БД идентификатор -1?
Что значит «кто-то»? Сериализацию объекта в БД Вы сами и должны написать. Что бы потом пользователи этим уже не страдали.
Не хочу.
Ну не хотите — используйте null. Но будьте готовы к тому, что пользователи Вашего API и на null не проверять, и исключения не обработают. А необработанные исключения — вечный гемор на задницу. Правда, уже не на Вашу, а на пользовательскую.
Это правило ввел не я — так работает БД. Что и позволяет мне в своем коде использовать диапазон <0 под свои корыстные нужды.
API проектируется для использования в конкретном языке (или конкретной технологии)
Хорошо, если это действительно так. А если Вы хотите обеспечить максимально возможный охват языков и платформ, базовая часть API должна быть максимально универсальной. Тогда можно будет реализовать это API в виде библиотеки на низкоуровневом языке (например, тот же С/С++), а потом по-быстрому наклепать оберток под другие языки (Java, Python, Ruby, Perl).
когда есть полностью корректный экземпляр «отсутствующих» данных
Именно это я и имел в виду, когда говорил про то, что объект класса, который isNull, может нормально функционировать. При этом Вы, как разработчик класса, можете это обеспечить, а те, кто будет использовать Ваше API, будут иметь возможность забыть про проверку и тем не менее получить работоспособный код.
Во многих современных языках null — это (отсутствующий) экземпляр определенного класса.
Во многих — но не во всех. И это при проектировании API нужно учитывать.
Собственно, потому и не ругают. ))
Сразу вспомнился анекдот про программистов.
Пациент приходит к программисту-хирургу:
— Доктор, у меня нога болит.
Доктор смотрит внимательно на свою и говорит:
— Странно, у меня такая же, но не болит.
А когда будет Tizen 3, пока не известно?
Я пробовал программировать под Tizen 2.1 в рамках Tizen Developer Lab в Нижнем Новгороде. Логика на js — это медленно, а взаимодействие js и С++ — это печально.
Будем надеяться, что сейчас наковыряют уязвимостей по-максимуму и пофиксят, потом поспокойнее станет. Все-таки лучше знать, что уязвимость была, но исправлена, чем вообще о ней не знать.
Проще — не значит правильнее. Вы подсовываете пользователю общие исключения, я предпочитаю предоставлять ему более подробную информацию. Что лучше в использовании в конечном счете — решает сам пользователь.
Лучше тем, что можно выбрасывать более понятные исключения. Если брать пример с сотрудником: программист вызывает метод fire() у Null Object и получает в ответ не стандартное исключение «TypeError: Cannot read property 'fire' of null» (как, например, в javascript), а Ваше, где более человеческим языком написано «попытка удаления несуществующего сотрудника», ну или что-то подобное.
Ну я бы сделал так, чтобы ошибку выдавал сам объект, но Вам почему-то этот вариант не нравится.
Если Вы хотите пример — поясню:
Класс Object пишется таким образом, что если объект является невалидным (Null Object), то при попытке доступа к данным этого объекта либо выбрасывается исключение, если Вы используете исключения, либо выдаются такие же null объекты, если Вы исключения не используете. При этом принцип подстановки Лисков не нарушается, хотя бы потому, что тип вообще один и не имеет подтипов.
Null Object выдаст ошибку там, где это будет нужно. И если Вы забудете ее сгенерировать в нужной ситуации, то это будет исключительно Ваша ошибка как разработчика API, а не как не пользователя, который это API использует. А детали реализации
надо от пользователя скрывать (это называется инкапсуляция), чтобы он не имел прямой доступ к полям класса, а использовал соответствующие методы.
Именно поэтому и надо сделать сериализацию за пользователя. Если он вдруг захочет сделать свою, ему никто не помешает накосячить там как угодно. Но по крайней мере одна работающая реализация от разработчика API будет.
См. выше http://habrahabr.ru/post/224929/#comment_7656745
Что значит «кто-то»? Сериализацию объекта в БД Вы сами и должны написать. Что бы потом пользователи этим уже не страдали.
Ну не хотите — используйте null. Но будьте готовы к тому, что пользователи Вашего API и на null не проверять, и исключения не обработают. А необработанные исключения — вечный гемор на задницу. Правда, уже не на Вашу, а на пользовательскую.
Это правило ввел не я — так работает БД. Что и позволяет мне в своем коде использовать диапазон <0 под свои корыстные нужды.
Хорошо, если это действительно так. А если Вы хотите обеспечить максимально возможный охват языков и платформ, базовая часть API должна быть максимально универсальной. Тогда можно будет реализовать это API в виде библиотеки на низкоуровневом языке (например, тот же С/С++), а потом по-быстрому наклепать оберток под другие языки (Java, Python, Ruby, Perl).
Именно это я и имел в виду, когда говорил про то, что объект класса, который isNull, может нормально функционировать. При этом Вы, как разработчик класса, можете это обеспечить, а те, кто будет использовать Ваше API, будут иметь возможность забыть про проверку и тем не менее получить работоспособный код.
Во многих — но не во всех. И это при проектировании API нужно учитывать.