转换数据时如何避免违反 SRP
在编写将数据从格式 A 转换为格式 B 的类时，如何避免违反“单一职责原则”？ 这样一个类的改变有两个原因，因为格式 A 和 B 的规范都可以改变。
How can I avoid violating the "single responsibility principle" when writing a class which should transform data from format A to format B?
There are exactly two reasons for such a class to change, because specifications of both, format A and B can change.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
所以，我是新来的，在发布这篇文章时，我在提出我的答案时提出了警告。
在我看来，到目前为止人们只能接受“单一责任原则”这样的概念。对我来说，转换类的唯一职责是管理数据从一种格式规范到另一种格式规范的转换。一些想法：
从最严格的角度来说，如果其中一种格式发生变化，理论上您仍然需要以前版本的格式转换器来转换旧数据（向后兼容）。你永远不知道什么时候有人可能无法收到有关格式更改的备忘录。或者您可能会在地下室的某个地方遇到一批格式为 A v1 的数据。因此，您的类的单一职责仍然是将数据从格式 A1.0 转换为格式 b1.0。
如果其中一项规范发生变化，您现在必须创建类的新版本，对吧？假设有人修改了格式 A 的规范。现在您需要一个类来管理数据从格式 A1.1 到 B1.0 的转换。您创建了一个具有单一职责的新类。
虽然在您的项目范围内，您可能不会考虑向后兼容的需求，但就 SRP 概念而言，我的理解是，一个或两个格式规范的更改需要定义一个新类，并且从学术理论最严格的角度来看，这并不意味着不止一种责任。
最后，如果您认为将数据从一种格式映射到另一种格式是类的单一职责，那么对任一规范的更改仍然只需要更改类的单一作业。
最后一个例子。假设我的班级的责任是将特定的红色色调转换为特定的粉色色调。然后有一天，首席设计师决定他想要一种更亮的粉红色作为输出，我的规格的一侧发生了变化，但我的班级的责任没有变化。第二天，公司最高层决定新的红色标准更像栗色。现在我的输入规范发生了变化，但我的班级的责任没有变化。我可能决定创建一个新类，并保留 1.0 版本以供保留，或者我可能只是更新现有版本。无论哪种情况，该类仍然具有单一职责；将红色规格映射到粉色规格。
So, I am new here, and post this with the caveat that I am stretching in proposing my answer.
It seems to me that One can only take concepts like the "Single Responsibility Priciple" so far. To me, the single responsibility of your transform class is to manage the translation of data from one format specification to another. Some thoughts:
In the strictest of terms, if one of the formats changes, you theoretically would still need the previous version of the format converter for converting legacy dat (backward compatibility). You never know when someone might not get the memo about the change in formats. Or you might run into a batch of data in format A v1 in the basement somewhere. Therefore, the single responsibility of your class would remain the conversion of data from format A1.0 to format b1.0.
If one of the specifications DOES change, you now have to create a new VERSION of your class, right? Let's say someone modifies the spec for format A. Now you need a class which manages the transformation of data from format A1.1 to B1.0. You have created a new class with a single responsibility.
While in the scope of your project, you may not consider the need for backward compatibility a requirement, in terms of the SRP concept, my understanding is that a change in one or both of the format specs requires the definition of a new class, and does not, in the strictest terms of the acedemic theory, imply more than one responsibility.
Lastly, if you think of the mapping of data from one format to another as the single responsibility of the class, then a change to EITHER spec still only necessitates a change to the single job of the class.
A final example by illustration. Assume the responsibility of my class is to transform a particular shade of red into a particular shade of pink. Then one day the cheif designer decides he wants a brighter pink as the output, one side of my spec has changed, but the responsibility of my class has not. The next day, it is decided at the very highest corporate level that the new red standard is more like maroon. Now my input spec has changes, but the responsibility of my class has not. I might decide the create a new class, and retain version 1.0 for holdovers, or I might just update the existing version. In either case, the class still has a single responsibility; mapping the red specification to the pink specification.