我有以下架构:
+-----------------+
| Collection |
| |
| |
| |
| |
+-----------------+
| ^
| |
Create() | |
| |
v | GetItem(B)
+------------+ |
| Item A | |
| | |
| +------+
| |
+------------+
管理项目集合的类,创建项目.这些物品可能需要集合中的其他物品.
实际的代码是python,现在Collection将自身作为参数传递给创建的Item.在我看来,这是一个不好的做法.唯一的改进我可以看到它传递Item所需的Collection的几个函数,而不是整个实例.
例如:
class Collection:
GetItem(self, id):
...
CreateItem(self, id):
item = Item(id, self) # <-- pass self
...
class Item:
__init__(self, id, col):
...
col.GetItem(...)
如何避免将self作为参数传递?或者它是Python中的常见用法?
更详细的例子
┌──────┐ ┌──────────┐ ┌─────┐
│Client│ │Collection│ │ItemA│
└──┬───┘ └────┬─────┘ └──┬──┘
│ UpdateItem(A, param)│ │
│ ────────────────────> │
│ │ │
│ │ Update(param, self)│ ╔═════════════════════════════╗
│ │ ───────────────────> ║Need to update linked ItemB ░║
│ │ │ ╚═════════════════════════════╝
│ │ GetItem(B) │
│ │ <───────────────────
│ │ │
│ │ ItemB │
│ │ ─ ─ ─ ─ ─ ─ ─ ─ ─ >
│ │ │
│ │ │────┐
│ │ │ │ UpdateItemB()
│ │ │<───┘
┌──┴───┐ ┌────┴─────┐ ┌──┴──┐
│Client│ │Collection│ │ItemA│
└──────┘ └──────────┘ └─────┘
最佳答案 一个非答案:鉴于目前的细节水平,推荐一个特定的模式是错误的方法!从DDD的角度来看,我想知道你是否应该退一步,并且应该从整体上看你的模型.
看起来你的“集合”类中至少有两个职责混在一起:
>创造物体的知识
>并更新它们
DDD建议让factories负责创建对象.
而不是考虑提供对各种条目的访问的集合,您可能宁愿定义聚合,并标识它们的root objects.因为您要确保只有一个定义的“路径”来获取某些信息.
换句话说:您应该努力设计一个模型,为您正在处理的现实世界元素提供有用的抽象.而你当前的实现感觉就像是从一些技术思想演变出来的东西.因此建议:退一步看看大图.