我正在考虑一种情况,即我有一个对象“交易”,它有相当多的属性,如帐户,金额,日期,货币,类型等。
我从不计划改变这些数据点,计算逻辑将存在于其他类中。我的问题是,为了保存数据,实例化成千上万个对象的Python设计是否糟糕?我发现数据嵌入在类中更容易,而不是试图将其嵌入到某些数据结构组合中。
答案 0 :(得分:8)
不,这完全没问题。实际上,Python在标准collections
模块中支持它:
from collections import namedtuple
Transaction = namedtuple("Transaction", ["account", "amount"])
而不是class Transaction(object):
等。请注意namedtuple
是一种“类工厂”,您需要将要构造的类的名称作为字符串传递给它。这不一定是你绑定结果的名称,但这样做仍然是一个好主意。命名元组类型类似于Pascal中的记录或C中的结构:具有命名成员但没有自己的重要行为的数据持有者。
用法:
>>> t = Transaction(account="my private account", amount=+1000)
>>> t
Transaction(account='my private account', amount=1000)
>>> t.amount
1000
>>> t.amount += 1
Traceback (most recent call last):
File "<ipython-input-6-ae60188f2446>", line 1, in <module>
t.amount += 1
AttributeError: can't set attribute
答案 1 :(得分:1)
我想说无论如何所有的值都是对象。假设代替事务类实例,你将有一个字典{'事务名称':[123,'GBP','12/12/12',1234,'in']}。现在这个字典又是一个对象,区别在于它不是你自己的类。无论如何,一切都是一个对象。事物是一个物体的事实,并不会自动使它笨重,大,慢或其他什么。可能您仍然需要考虑这些事务中有多少这些事件要在给定时间内保留在内存中?
我认为这是明确的代码设计问题。让我们说现在你有一本具有行动方法的课本,接受交易对象作为属性。当这个动作方法将使用对象属性时,它将比例如引用列表的第n个元素更清楚。
它是一个类,它也让你有机会在将来修改或添加功能。例如,您可能希望在某个时刻添加所有事务的记录或撤消方法。