Определение атрибутов объектов / сущностей в python / Google app engine

Я видел повторяющиеся примеры, подобные этому: 

from google.appengine.ext import db
import datetime

class Book(db.Expando):
    pass

obj = Book()
obj.title = 'The Grapes of Wrath'
obj.author = 'John Steinbeck'
obj.copyright_year = 1939
obj.author_birthdate = datetime.date(1902, 2, 27)

obj.put()

Я впервые столкнулся с такого рода кодом, где атрибуты задаются вне определения класса. Мне кажется, это очень плохая практика. Я предпочитаю: 

class Book(db.Model):
    title = db.StringProperty()
    author = db.StringProperty()
    copyright_year = db.IntegerProperty()
    author_birthdate = db.DateProperty()

...
    obj = Book(title='The Grapes of Wrath', author='John Steinbeck', copyright_year=1939, author_birthdate=datetime.date(1902, 2, 27))
Может ли кто-нибудь дать гарантию относительно характера практики автора? Где и когда такой метод будет приемлемым? Было упомянуто, что модель хранения данных google обеспечивает необычную гибкость. Я так и думал примером может быть слабое и слишком тонкое введение в эту концепцию. Автор фактически указал на недостатки этого стиля,но продолжает его повторять. Так что, возможно, в этом есть какое-то преимущество.
2 2
python class-design google-app-engine

2 ответа:

Это задокументировано здесь. Приведенный фрагмент является допустимым, хотя не ясно, почему класс полностью пуст (возможно, для иллюстрации). Я полагаю, что главный вопрос заключается в том, когда использовать модель Expando ?

Представьте себе сайт, собирающий заказы на все возможные виды товаров. Один клиент может захотеть заказать котенка, другой-книгу и т. д. Книги и котенок имеют очень мало общего, может быть, только цену и вес. Но мы хотим например, один клиент может заказать котенка 3-месячного, Сиамского, голубоглазого, а другой - "Властелина колец" 2-го издания, в твердом переплете, с автографом автора и т. д. Хотя эти свойства не актуальны в момент получения заказа, они жизненно важны для вашей бизнес-логики. Кроме того, вы можете обработать эти свойства позже.

Единственным решением здесь является использование модели Expando, поскольку вы не можете создать универсальный класс (или иерархию классы), охватывающие все существующие свойства. Модель Expando будет содержать все общие свойства (цена, вес, идентификатор отслеживания, стоимость доставки, таможенные сборы и т. д.) и методы (подсчет итога, скидки и т.д.), остальные свойства будут созданы клиентом динамически во время выполнения. Экземпляр модели будет сохранен в хранилище данных со всеми его свойствами, и любой конкретный экземпляр вернет все свойства, определенные в нем через модель.метод properties ().

3

Это смешно. Я читал ту же книгу и думал о том же самом. Я использую приложение движок на Python, поскольку он был запущен и никогда не используют модели расширенного.

Я думаю, что намерение автора состояло в том, чтобы облегчить читателям, которые, возможно, не знакомы с классами Python, концепцию определения моделей, но я не нашел это полезным.

Однажды гибкость хранилища данных пригодилась мне, когда я переключил поле в одной из своих моделей с использования DateTime на использование пользовательского строкового свойства. Сущности с полями обоих типов могли жить бок о бок, и я мог переносить их по мере доступа к каждому из них.

2