这违反了SRP吗？
我经常对书中所述的“改变”或“变革轴的理由”感到困惑。
我有一个让角色用手抓住物理对象的课程。
可抓取的对象本身是另一个知道如何获得这些“抓点”的班级，因此Grabber类知道将角色的手放在哪里。
我认为这看起来正确，因为每个班级都有不同的责任。
但是它们是如此的耦合，以至于他们只能成为一个班级几乎是有意义的。从现在开始，这会破坏SRP，从而扫描抓点，并将角色的手移到对象上，同时仍被掌握地使用？
I often get confused about the "reason to change" or "an axis of change" stated in the book.
I have a class that makes a character grab a physics object with its hands.
The grabbable object itself is another class that knows how to get these "grab points" so the grabber class knows where to put the character's hands.
I think this looks right since each class has distinct responsibilities.
But they are so coupled that it almost makes sense for them to be one class only. Would that break SRP since now the class scans for grab points and also moves/attaches the hands of the character to the object, while still being used cohesively?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SRP在做更多的“一件事”时不会告诉您分裂。无论如何，这是模棱两可的，因为程序是功能性层次结构 - 程序所做的所有“事物”都是较小的事物。
SRP告诉您，当他们拥有一个以上的责任范围时，就像一个拥有两个老板的工人一样。这会导致问题，因为一个老板的指示可能与另一个老板想要的是不符。
在您的情况下，您需要一堂课来处理抢夺行为是有道理的。这是您想更改抓取方式时修改的班级 - 这是其责任。
您应该拥有每种/类型的对象类型的类，并且该类应确定对象的抓取点，以及对象的所有其他属性，就像其形状一样。这是您要更改对象时修改的类 - 这是其责任。
您是否需要一个单独的扫描类来扫描对象定义以获取抓取点？可能不是。我通常希望对象类具有返回其抓点的方法。遵循其他固有原则，可能应该有一个单独的
grabbable接口，必须实现对象类才能被抓取，并且该接口将定义返回抓取点的方法。因此，希望您现在了解SRP现在的含义，但是请记住，没有最好的方法 划分您的程序并确定这些责任范围。决定如何以最能满足您所有功能和组织要求的方式做到这一点，主要是软件设计是，这并不容易。
特别是，如果您正在制作游戏，请研究 noreflow noreferrer“>实体，组件，系统，系统模式。这是构建游戏实现的一种非常流行的方式，可能会产生与您的想法完全不同的分解方式。
The SRP does not tell you to divide classes when they do more than "one thing". That's ambiguous, anyway, since programs are functional hierarchies -- all the "things" that programs do are groups of smaller things.
The SRP tells you to divide classes when they have more than one line of responsibility, like a worker with two bosses. That causes problems, because one boss' instructions might be at odds with what the other boss wants.
In your case, it makes sense that you would want a class that handles the grabbing action. This is the class that you modify when you want to change how grabbing works -- that's its responsibility.
It also makes sense that you should have a class for each kind/type of object, and that class should determine the object's grab points, along with all the other attributes of the object like its shape. This is the class that you modify when you want to change the object(s) -- that's its responsibility.
Do you need a separate scanning class that scans the object definition for grab points? Probably not. I would normally expect the object class to have a method that returns its grab points. Following the other SOLID principles, there should probably be a separate
Grabbableinterface that the object class must implement in order to be grabbable, and this interface would define the method that returns grab points.So hopefully you understand what SRP means now, but bear in mind that there is no best way to divide up your program and determine these lines of responsibility. Deciding how to do this in a way that best meets all of your functional and organizational requirements is mostly what software design is, and it isn't easy.
In particular, if you are making a game, then investigate the Entity, Component, System pattern. This is a very popular way to structure game implementations that is likely to produce a completely different decomposition from what you had in mind.
但是，很难说是否可以将课程合并为一个，但是，对于第一份看来，您有两个职责，例如：
所以我会坚持两个类。因为如果我们仅坚持一个班级，那么此课程将有两个理由进行更改，调试或编辑。
因此，因此，如果您的课程较小并且只有一个目标，则以后为您的课程进行单元测试会更容易。
It is really hard to say whether the classes can be merged into one, however, for the first glance, it looks like you have two responsibilities such as:
So I would stick with two classes. Because if we stick with just one class, then this class will have two reasons to be changed, debugged or edited.
So, as a result it will be easier to write unit tests later for your if your classes will be smaller and just have one goal.