包稳定性指标，但是对于特定类别？
我想知道是否有一个类似于 Robert Martin 定义的包稳定性指标的指标，可以通过其不稳定性 (I) 指标来了解一个包何时应该或不应该依赖于另一个包
Ca = Afferent Couplings
Ce = Efferent Couplings
I = Ce / (Ce+Ca)
：包内的类与其他包中的类之间的传入和传出耦合；它们在同一包内的类之间进行传入和传出耦合（也许和/或其他包，我真的不知道），让人们知道一个类是否应该或不应该依赖于另一个类，通过其“不稳定”。
编辑：据说不稳定指标衡量改变的原因：不改变比率的原因，但现在我想了想，一个类应该只有 1 个改变的理由，这意味着如果存在这样类似的不稳定性指标，那么我会为 0，但是某些类仍然“使用”其他类的对象实例，使它们依赖于这些类；但我对此不确定，对此有什么见解吗？
I'm wondering if there's a metric similar to the Package Stability Metric defined by Robert Martin that can be used to know when a package should or shouldn't depend on another, by its Instability (I) metric:
Ca = Afferent Couplings
Ce = Efferent Couplings
I = Ce / (Ce+Ca)
But for classes, where instead of being Afferent and Efferent couplings between classes inside a package to classes in other packages; they where afferent and efferent couplings between classes within the same package (maybe and/or also other packages, I don't really know), letting one know if a class should or shouldn't depend on another class, by its 'instability'.
Edit: Supposedly the Instability metric measures the reasons to change : reasons not to change ratio, but now that I think about it, a class should have only 1 reason to change, meaning that if such similar Instability metric existed, a class' I would be 0, but still, some classes do 'use' object instances of other classes, making them dependent of those classes; but I'm uncertain of this, any insights on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
传入和传出耦合是类的有效度量，并且可以计算类的不稳定性。您可以在类上使用 Instability 来确定在何处重点创建稳定或不稳定的类 - 但实际上这可能会导致一些糟糕的设计选择。
例如，不稳定组件应具有尽可能少的依赖项（传入耦合），而稳定类应具有尽可能少的依赖项（传出耦合）。在富域模型中，很可能存在双向关联 - 这意味着无论您的类是稳定的还是不稳定的，您都开始违反与度量相关的“规则”。请注意，在包/组件级别，不鼓励甚至禁止任何循环依赖项。
您最好将精力集中在较大的组件上，即包或层。一般来说，您希望您的域模型应该稳定（当您更改域时，您这样做是因为这代表了对域的实际更改，或者至少是您对域的理解）。更可能发生变化的事物（例如视觉元素和数据访问组件）是不稳定的，并且对域具有依赖性。
Afferent and Efferent coupling are valid metrics on a class, and it is possible to calculate Instability for a class. You could use Instability on a class to determine where to focus on creating stable or instable classes - but in practice this could lead to some poor design choices.
For example, instable components should have as few dependers (Afferent coupling) as possible, while Stable classes should have as few dependencies (Efferent coupling) as possible. In a rich domain model , it is quite possible to have bi-directional associations - meaning you are beginning to violate the "rules" associated with the metric no matter whether your classes are intended to be stable or instable. Notice that at a package/component level, any cyclical dependencies are discouraged or even prohibited.
Your efforts are better spent focusing on larger components, i.e. packages or layers. Generally, you want your Domain model should be stable (when you change the domain, you do so because this represents an actual change to the domain, or at least your understanding of the domain). Things that are more likely to change, such as visual elements and data access components are instable, and have dependencies on the domain.