После выполнения сценариев update_db_shelve.py и dump_db_shelve.py можно заметить, что была добавлена новая запись с ключом tom и на 50 процентов был увеличен оклад Сью. Эти изменения сохраняются между запусками сценариев, потому что записи-словари отображаются модулем shelve во внешний файл хранилища. (Этот сценарий особенно хорош для Сью - у нее могло бы появиться желание почаще запускать этот сценарий с помощью планировщика cron в Unix или поместив его в папку Автозагрузка (Startup) с помощью msconfig в Windows...)
Что в имени тебе моем?
Удивительно, но часто остается тайной, что свое название язык Python получил благодаря британскому телевизионному комедийному сериалу «Monty Python’s Flying Circus», появившемуся на экранах в 1970-х годах. Фольклор сообщества Python утверждает, что Гвидо ван Россум (Guido van Rossum), создатель Python, смотрел повторные показы этого сериала как раз в то время, когда подбирал название для нового языка программирования, который он разрабатывал. И, как говорят в шоу-бизнесе: «остальное уже история».
Такая наследственность часто является причиной появления в примерах и обсуждениях ссылок на комедийную игру. Например, в сценариях часто используется имя Brian; словами spam (консервированный фарш), lumberjack (лесоруб) и shrubbery (кустарник), получившими специальное значение, называют пользователей Python; а презентации иногда называют «испанской инквизицией». Как правило, когда пользователь Python начинает произносить фразы, не имеющие отношения к реальности, они оказываются заимствованными из сериала или фильмов с участием персонажа Monty Python. Некоторые из этих фраз могут встретиться даже в этой книге. Конечно, чтобы писать программы на языке Python, необязательно бежать и брать в прокате «The Meaning of Life» или «The Holy Grail», но и хуже от этого не будет.
Имя «Python» быстро прижилось, тем не менее его заимствование стало причиной интересных курьезов. Например, когда в 1994 году возникла телеконференция по Python, comp.lang.python, первые несколько недель она практически полностью была оккупирована желающими обсуждать темы, касающиеся телевизионной постановки. Позднее специальное приложение к журналу «Linux Journal», касающееся Python, стало сопровождаться фотографией Гвидо, облаченного в обязательную «красную форму».
В списке рассылки Python все еще появляются случайные письма от поклонников сериала. Например, в одном письме невинно предлагалось обмениваться сценариями с участием персонажа Monty Python. Если бы автор письма понимал назначение форума, то хотя бы указал, могут ли они выполняться в разных операционных системах или нет.
Шаг 3: переход к ООП
Давайте отвлечемся на минутку и посмотрим, куда мы пришли. Итак, в настоящий момент у нас имеется две реализации базы данных: на
основе модуля shelve и на основе модуля pickle, в которой каждая запись сохраняется в отдельном файле, - этого вполне достаточно для хранения простых данных. Наши записи представлены простыми словарями, которые обеспечивают более простой и понятный доступ к полям, чем списки (то есть не по числовым индексам, а по ключам). Однако словари имеют некоторые ограничения, которые могут оказаться существенными по мере разработки программы.
Во-первых, у нас не предусмотрено место для централизованного хранения логики обработки записей. Операции извлечения фамилии и увеличения оклада, например, могут выполняться так:
>>> import shelve
>>> db = shelve.open(‘people-shelve')
>>> bob = db[‘bob']
>>> bob[‘name'].split()[-1] # вернет фамилию Боба ‘Smith’
>>> sue = db[‘sue']
>>> sue[‘pay'] *= 1.25 # увеличит оклад Сью
>>> sue[‘pay']
75000.0
>>> db[‘sue'] = sue >>> db.close()
Такое решение вполне пригодно для небольших программ. Но если когда-нибудь потребуется изменить логику извлечения фамилии или увеличения оклада, нам, возможно, придется обновить подобный программный код во множестве мест в программе. На практике даже просто отыскать все такие фрагменты может оказаться достаточно сложным делом - копирование одинаковых фрагментов программного кода рано или поздно обязательно даст знать о себе.
Подобные фрагменты предпочтительнее скрывать, то есть инкапсулировать. Эти операции можно было бы реализовать в виде функций в одном модуле и тем самым избежать избыточности, но при таком подходе функции никак не будут связаны с самими записями. Нам же желательно связать логику обработки с данными, хранящимися в базе данных, чтобы ее проще было понимать, отлаживать и многократно использовать.
Другой недостаток использования словарей для представления записей заключается в том, что со временем их становится трудно расширять. Например, представьте, что имеется набор полей данных или различные процедуры, увеличивающие оклад для разных сотрудников по-разному (например, кто-то может получать ежегодную прибавку, а кто-то - нет). Если нам когда-нибудь потребуется расширить программу, сделать это будет очень сложно, так как нет простого и естественного способа расширить простые словари. С учетом дальнейшего роста нам