使用“单一责任原则”迫使我的容器拥有公共制定者
我正在努力按照SOLID原则进行设计。 我发现当你使用“单一责任原则”(SOLID的S)时,你通常必须在数据容器和数据处理器之间拆分类。 例如,如果我有一个具有5个属性的类人员从DB读取而不是将所有内容放在一个类中,我创建一个带有属性的Person类和另一个从数据库中读取该信息并创建Person的PersonReader类。
如果我这样做,我必须打开Person属性,以便PersonReader可以访问它们,但是我的封装比将所有内容放在黑盒子中并使属性只能读取更少。
我错过了什么或这是这个原则的缺点吗?
提前致谢
编辑:我已经将人作家改为一个人读者,因为没有必要在开始时公开财产制定者。
大多数数据访问策略(ORM技术)涉及您所描述类型的妥协。 最少侵入性的使用reflection(或内省等)在需要时填充您的实体(例如,当没有公共设置者时)。
话虽如此,如果你的实体只是数据容器(如在贫血域模型中 ),单一责任原则不应该真正关心你,因为你的对象没有复杂的逻辑会被破坏(或干扰)数据访问代码。
也许我错过了什么,但你为什么不为Person类编写一个接受它所有属性的构造函数呢? 通过这种方式,PersonReader将能够在不打开人员属性的情况下创建人员。
另一种选择是将人员属性的setter标记为内部(并使组件内部对PersonReader的程序集可见,如果它在不同的程序集中)。 这将允许您访问人员属性,但会阻止任何人在程序集之外更改它们。
我绝对同意你的意见,有时你会遇到这个问题。 我经历过序列化,它类似于ORM。 在我的情况下,我需要将对象的状态写入(二进制)文件。
在某些情况下,可以创建一个接口,通过该接口可以写入和读取内部状态。 因此,您的人员课程将获得两个“保存”和“加载”(或“写入”和“阅读”或您认为合适的任何内容)。 这些方法分别通过“IPropertyWriter”和“IPropertyReader”。 (在我的例子中,我称他们为InStream和OutStream)。
然后,Person :: save(IPropertyWriter writer)会这样做
writer.writeProperty("name", this.name); writer.writeProperty("age", this.age);
你可以说你仍在违反单一责任原则,但我认为没有其他人应该知道人的内部。 (特别是在我的序列化的情况下,我不得不存储部分无法通过getter访问的内部状态)。 重点是Person没有耦合到任何数据库代码。 您的IPropertyWriter可以是一切。 此外,“了解自己的属性”的责任并不是真正的新属性,而是附加到每个对象上。
你可能也会问这个人改变的可能性有多大。 如果它不太可能,我认为C ++中的friend
类是一种好方法,但是如果它可能会改变,我宁愿在声明属性的地方使用序列化方法,所以你不要忘记更新依赖代码。
你太精细了。 特定的类应该读取数据库 – 但是您不需要一个唯一的工作就是创建Person的类。 那太浪费了。 单个数据库阅读器应该能够创建通过数据库的任何类 – 因为这是它的工作。 从数据库中读取。
打开Person的属性没有封装问题,因此DatabaseReader可以访问它们,因为如果没有类能够创建它,则Person是多余的。 任何类别的责任都是可创造和可破坏的固有部分。
上述就是C#学习教程:使用“单一责任原则”迫使我的容器拥有公共制定者分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/991836.html