我最近一直在思考面向对象的原则/实践/范例,例如 SOLID、Demeter 法则和 DDD,并且不断浮出水面的主题是强制对象基数。
对象关联基数源自业务规则,这些规则规定某些实体只能与一定数量的其他实体对象相关联。例如,如果您正在设计一个管理仓库的系统,业务规则可能是单个项目只能存储在一个仓库中。显然,在软件设计中强制执行这些规则是一个实现问题。
我想知道的是:如果业务领域需要严格的基数模型,那么执行它的最佳方式是什么?我能立即想到的技术包括:
双向引用 - 关联对象之间的双向关联(对象 A 引用对象 B,对象 B 引用对象 A)
class Warehouse { private List<Item> items; public void RegisterItem(Item obj) { if(obj.Warehouse != null) throw new ArgumentException("Can only register un-owned item") items.Add(obj); obj.Warehouse = this; } }
封装拥有的实体 - 让所有者控制它的创建和删除,并通过一组抽象实际实体实现的 API 提供访问(对象 A 克隆传入的实体 B 或根据传递的原理图创建实体 B)
class Warehouse { private List<Item> items; public void RegisterItem(Item obj) { items.Add((Item)obj.Clone()); } public void RegisterItem(ItemDescriptor item) { items.Add(new Item(item)); } }
第三方监控 - 让一些了解基数约束的第三方适本地创建和连接对象关联(对象 C 知道 A 和 B 之间的关系并负责创建和维护它- 此方法仅对C可用,对客户端不可用)
class Warehouse { private List<Item> items; internal void RegisterItem(Item obj) { items.Add(obj); } } class WarehouseItemRegistrationService { private List<Item> registeredItems; public void RegisterItem(Warehouse warehouse, Item item) { if(registeredItems.Contains(item)) throw new ArgumentException("Can only register un-owned items"); warehouse.RegisterItem(item); } }
我认为每种技术都有其优点和缺点。 双向关联 会增加对象图的复杂性并需要私有(private) API 来更新引用,但实现起来非常简单,并将业务约束嵌入到业务实体类中。 封装拥有的实体可以通过强制实体具有基于值的描述来使域模型复杂化,但它非常干净。 第三方监控技术将显式基数强制执行隔离到一个单独的类,但它也使领域模型复杂化。
有没有人有任何其他想法、想法或更好的方法?
最佳答案
建立协会不是任何一个类(class)的责任。将其留给中介来创建链接。
创建一个关联类 WarehouseItem
来表示关联,并创建一个 WarehouseItemFactory
类来通过创建 WarehouseItem
的实例来建立关联。 WarehouseItemFactory
将负责执行基数规则。
关于oop - 实现对象关联基数的模式和实践,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/7589080/