2012-06-23 32 views
7

Tôi đang suy nghĩ về một tình huống mà tôi có đối tượng "Giao dịch", có một số thuộc tính như tài khoản, số tiền, ngày, loại tiền tệ, loại, v.v.Đối tượng Không có hành vi

Tôi chưa bao giờ lập kế hoạch để thay đổi các điểm dữ liệu này và logic tính toán sẽ tồn tại trong các lớp khác. Câu hỏi của tôi là, nó là thiết kế Python nghèo để khởi tạo hàng ngàn đối tượng chỉ để giữ dữ liệu? Tôi tìm thấy dữ liệu dễ dàng hơn để làm việc với nhúng trong một lớp hơn là cố gắng nhồi nhét nó vào một số kết hợp của cấu trúc dữ liệu.

Trả lời

8

Không, điều này hoàn toàn ổn. Trong thực tế, Python đã hỗ trợ cho nó trong tiêu chuẩn collections mô-đun:

from collections import namedtuple 

Transaction = namedtuple("Transaction", ["account", "amount"]) 

thay vì class Transaction(object): vv Lưu ý rằng namedtuple là một loại "nhà máy lớp" và bạn cần phải vượt qua nó là tên của lớp được xây dựng, như một chuỗi. Điều đó không cần phải là tên mà bạn gắn kết quả, nhưng làm như vậy vẫn là một ý tưởng hay. Các kiểu tuple được đặt tên tương tự với các bản ghi trong Pascal hoặc các cấu trúc trong C: các chủ sở hữu dữ liệu có các thành viên được đặt tên nhưng không có hành vi quan trọng nào của chúng.

Cách sử dụng:

>>> 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 
+0

Câu trả lời hay và cách tôi làm. Cách duy nhất tôi có thể nghĩ ra nếu một số trường bị thưa thớt sẽ là 'dict' (có khả năng tiết kiệm trên' __slots__') –

+0

@JonClements: cấu trúc sẽ rất thưa thớt để đảm bảo sử dụng 'dict', vì phân bổ bằng số lượng lớn (ít nhất 1/3, tôi tin). –

+0

Yup - nhưng tôi nghĩ tôi sẽ ném nó vì mục đích đầy đủ. Với trường hợp sử dụng của OP, câu trả lời của bạn (với tôi ít nhất) là chính xác và phải được chấp nhận. –

1

Tôi có thể nói rằng tất cả các giá trị này là đối tượng nào. Giả sử rằng thay vì phiên bản lớp giao dịch, bạn sẽ có từ điển {'tên giao dịch': [123, 'GBP', '12/12/12', 1234, 'in']}. Bây giờ từ điển này lại là một đối tượng và sự khác biệt là nó không phải là lớp của riêng bạn. Mọi thứ vẫn là một đối tượng. Thực tế là một cái gì đó là một đối tượng, không tự động làm cho nó cồng kềnh, lớn, chậm hoặc bất cứ điều gì. Có lẽ bạn vẫn cần xem xét về các giao dịch này về số lượng đối tượng bạn muốn giữ trong bộ nhớ trong một thời gian nhất định?

Đó là vấn đề về thiết kế mã rõ ràng theo ý kiến ​​của tôi. Cho phép nói rằng bây giờ bạn có một cuốn sách lớp có một phương thức hành động, chấp nhận các đối tượng giao dịch dưới dạng một thuộc tính. Khi phương thức hành động này sau đó sẽ sử dụng các thuộc tính đối tượng, nó sẽ rõ ràng hơn nhiều so với nếu nó đang đề cập đến các phần tử thứ n của một danh sách chẳng hạn.

Thực tế là đó là một lớp học cũng giúp bạn có cơ hội sửa đổi hoặc thêm chức năng trong tương lai. Ví dụ: bạn có thể muốn thêm nhật ký của tất cả giao dịch hoặc rút phương thức tại một số điểm.

+0

Tôi thấy quan điểm của bạn, nhưng OP đã tuyên bố: "Tôi không bao giờ có ý định thay đổi các điểm dữ liệu này, và logic tính toán sẽ sống trong các lớp khác." –

+0

Tôi nhận được điều đó, tôi luôn nghĩ như vậy và sau đó hóa ra tôi có thể thực sự cần phải thay đổi điều gì đó sau một vài tuần. Đây là những lý lẽ của tôi trả lời câu hỏi "... là thiết kế Python nghèo nàn để khởi tạo hàng nghìn đối tượng chỉ để giữ dữ liệu ...?" Tính linh hoạt của sự phát triển trong tương lai là một trong số đó. – Damian

Các vấn đề liên quan