Package stability metrics, but for specific classes?

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?

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.