Comments 8
Увидел заголовок. Решил, что это про прокрастинацию (ну или про отдых). Захотел почитать. А вы тут меня опять работать заставляете))
Так рождалась операционная система Nero... (для тех дедов, которые помнят)
О, ты не имеешь принтеров, да, ты не имеешь принтеров, о ты не имеешь принтеров
Если я правильно понял посыл, автор предлагает замести под ковер все неожиданные ситуации при работе с апи, мол, давайте апи будет заботиться о том, что кто-то может недостаточно тщательно подойти к тестированию (или невнимательно читать документацию) . Ну уж нет: явное лучше неявного. Если в системе нету принтеров, и в результате - о боже - вылетит исключение, то если его забыли обработать на этой системе - виноваты разработчики этой системы, а не апи (если, конечно, в документации апи явно указано, что такое-то исключение может быть брошено). Тем не менее, я соглашусь с тем, что изначально апи стоит проектировать так, чтобы оно не бросало исключений - в разных средах обработка исключений может быть тяжелой (привет с++) - лучше возвращать коды ошибок.
Мне показалось, что ситуация иная. API уже спроектировано до нас и не нами, и является частью некоторой системы. Мы же реализуем совместимую, насколько возможно, систему, которая этот API предоставляет, и хотим запускать на ней приложения, спроектированные для оригинальной системы. Но, как всегда, ресурсы ограничены, и чем-то нужно жертвовать. Автор рассказывает, как именно сделать заглушки для методов, которые мы не смогли или не успели реализовать.
В статье приведены примеры c оригинальной Windows и её версией для Xbox. Я бы их дополнил Windows и WINE, Windows и ReactOS, .NET и Mono (хоть это уже история), Windows и ExaGear.
Согласен с тем, что явное лучше не явного, но работать это будет только для разработки новых приложений. Существует тьма приложений, которые уже написаны и которые никогда не будут обновляться.
Автор предлагает использовать что-то типа принципа подстановки Лисков только в контексте апи. Новая реализация апи ничего не делает, но сохраняет все предусловия и постусловия старой реализации. На примере принтеров имитирует систему без оных.
Апи больше не поддерживаются, но старые приложения продолжат работать без ошибок. А это выгодно с точки зрения бизнеса.
Зачем вводить в заблуждение пользователя, выводя пустое окошко для принтеров и давая ему иллюзию, что он может настроить принтер? Вот столкнётся с этой ситуацией какой-нибудь подросток или настойчивый новичок, и увидев это окошко, решит, что возможность печати как бы есть, начнёт пробовать подключать к консоли домашний принтер, искать драйвера на сайте производителя, не найдя - начнёт бомбить техподдержку, потом искать драйвера в интернете (подцепив какой-нибудь вирус), и кто знает сколько ещё танцев с бубном понадобится пока он не поймёт, что это была заглушка, его обманули и печатать нельзя. Будет огромная обида и потеря времени. А всего-то надо выводить нормальную ошибку, что подсистема печати на данной ОС отсутствует, печать с xbox невозможна, извините.
With this behavior, when the app tries to print, it will ask the user to select a printer, and show an empty list. The user realizes, “Oh, there are no printers,” and cancels the printing request.
Чекнул оригинал на всякий случай, перевод верный.
Думаю, правильно было бы пользователя явно уведомлять, что печать на xbox не поддерживается. Нам же приложение нужно обмануть, а не пользователя.
Если вы собираетесь сидеть и ничего не делать, то хотя бы делайте это правильно