Discussion on:

Object-oriented design metrics ensure robust software

While theoretically interesting, though containing logical errors, the article is superfluous. When maintaining code the number of incoming dependencies is less important than what those dependencies are.

Having many incoming dependencies means touching a lot of code to make a change, but it might be simple to make the changes. Having fewer incoming dependencies that touch more intricate code presents more of a challenge. Because it ignores the effort/skill level involved in the changes but just uses a quantity measurement, the model presented does not measure maintainability and is essentially useless.

The discussion of abstractness contained errors that a basic proofread should have caught. The article states, "You measure the abstractness of a package by calculating the ratio of the number of abstract classes (and interfaces) in the package to the total number of classes in the package." The formula presented does not present a ratio based on total classes. It presents abstract over concrete.

I also was confused by the referential basis. The gist of this is that if I have things that depend on me then I have incoming dependencies. If I depend on other things then I have outgoing dependencies. This seems backward. I donot know that this referential terminology is a standard but it certainly is logically backward when presented in plain language.

I came away from this article with more questions that when I started. Will there, perhaps, be follow on articles that provide more depth on the various issues raised?

Some of my questions include:

What is being evaluated by these measurements? How and why should I adjust software to improve the measured values?

Do the terms "Stability" and "Abstractness" have some defined in a particular community that I am not aware of? If so, could this be provided, if not, could a mapping between common usage and the equations be provided?

I am sure that quite a bit of thought and research went into this article, but it seemed to jump straight into providing a pair of equations without setting the stage of why and how they might be used. Follow on articles providing more detail would be appreciated.

This article is heavily based on, and largely a restatement of the work that Robert C. Martin has done. Yet you give absolutely no credit to him, which is intellectually disrespectful at best. I would expect the editors of this site to be more diligent to guard against this type of thing.

For those who want more information on the concepts so briefly covered here, please see Robert's work at Object Mentor (objectmentor.com), as well as his books which can be found by searching for his nameat your favorite book seller site.

I was about to make the same remark:
It has to be a lack of honesty for a guy ready to count afferent and efferent links to a package to forget to credit his sources.

However I fully recommend to read Bob C. Martin original article or book sinceit is way more enlighting.

If a package is created and never changes, is it not stable because the number of packages using it is small? If a package changes every time it is reused and it is used by a large number of packages, is it stable? The proposed measures would indicate so. This is counter intuitive.

To me, stability is a measure of the amount or frequency of change. It does not take into consideration how easy or difficult the change is or how great the affect of the change.

The described measure of "stability" is actually a measure of dependecies. Such measures are useful for determining the complexity of a package or program and in estimating the amount of work needed for a change. But why should a commonly understood term be redefined? That causes confusion and misunderstanding.

Another measurment method of no use in practice. Stabiliy still stays in design (the selection of interface type, package data formats, etc).