问实施对象关联基数的模式与实践

EN

最近，我一直在思考面向对象的原则/实践/范例，例如SOLID、Law of Demeter和DDD，其中一个不断浮现的主题是执行对象基数。

对象关联基数是从强制某些实体只能与一定数量的其他实体对象相关联的业务规则派生的。例如，如果您正在设计一个管理仓库的系统，业务规则可能是单个项目只能存储在一个仓库中。显然，在软件设计中执行这些规则是一个实现问题。

我想知道的是:如果业务域需要严格的基数模型，那么执行它的最佳方式是什么？我可以马上想到的技术包括以下几点：

• Bi-directional引用-关联对象之间的双向关联(对象A引用对象B和对象B引用对象A)

类仓库{私有列表项；公共无效RegisterItem(项obj) { if(obj.Warehouse != null)抛出新的ArgumentException(“只能注册无所属项”) items.Add(obj)；obj.Warehouse = this；}让所有者控制其创建和删除，并通过一组抽象实际实体实现的API提供访问(在实体B中传递的对象A克隆或根据传递的架构创建实体B)。

类仓库{私有列表项；公共空RegisterItem(项obj) {items.Add((项)obj.Clone())；}公共空项(ItemDescriptor项){items.Add(新项(项))；}items.Add(新项(项目))；}obj.Clone--有一些第三方能够正确地理解基数约束，创建和连接对象关联(对象C知道A和B之间的关系，并负责创建和维护它--这种方法只对C可用，而对客户端不可用)

类仓库{私有列表项；内部无效RegisterItem(项obj) { items.Add(obj)；}类WarehouseItemRegistrationService {私有列表registeredItems；公共空RegisterItem(仓库仓库，项){if(registeredItems.Contains(项目))抛出新的ArgumentException(“只能注册非拥有项”)；warehouse.RegisterItem(项)；}

我认为每种技术都有其优点和弱点。双向关联可以增加对象图的复杂性，并需要私有API来更新引用，但是在业务实体类中实现和嵌入业务约束非常简单。封装拥有的实体可以通过强制实体具有基于值的描述来使域模型复杂化，但它非常干净。第三方监控技术将显式基数执行分离到一个单独的类，但它也使域模型复杂化。

有没有人有其他的想法、想法或更好的方法？