Coupling

Rules which find instances of high or inappropriate coupling between objects and packages.

CouplingBetweenObjects

Since: PMD 1.04

This rule counts the number of unique attributes, local variables, and return types within an object. A number higher than the specified threshold can indicate a high degree of coupling.

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.coupling.CouplingBetweenObjectsRule

Example(s):

import com.Blah;
import org.Bar;
import org.Bardo;

public class Foo {
   private Blah var1;
   private Bar var2;
 
 	//followed by many imports of unique objects
   void ObjectC doWork() {
     Bardo var55;
     ObjectA var44;
     ObjectZ var93;
     return something;
   }
}

    

ExcessiveImports

Since: PMD 1.04

A high number of imports can indicate a high degree of coupling within an object. This rule counts the number of unique imports and reports a violation if the count is above the user-specified threshold.

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.coupling.ExcessiveImportsRule

Example(s):
      
import blah.blah.Baz;
import blah.blah.Bif;
// 18 others from the same package elided
public class Foo {
 public void doWork() {}
}
      
  

LooseCoupling

Since: PMD 0.7

The use of implementation types as object references limits your ability to use alternate implementations in the future as requirements change. Whenever available, referencing objects by their interface types provides much more flexibility.

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.coupling.LooseCouplingRule

Example(s):

	// sub-optimal approach
private ArrayList list = new ArrayList();

public HashSet getFoo() {
	return new HashSet();
}

	// preferred approach
private List list = new ArrayList();

public Set getFoo() {
	return new HashSet();
}

      

LoosePackageCoupling

Since: PMD 5.0

Avoid using classes from the configured package hierarchy outside of the package hierarchy, except when using one of the configured allowed classes.

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.coupling.LoosePackageCouplingRule

Example(s):

package some.package;

import some.other.package.subpackage.subsubpackage.DontUseThisClass;

public class Bar {
   DontUseThisClass boo = new DontUseThisClass();
}
  
      

LawOfDemeter

Since: PMD 5.0

The Law of Demeter is a simple rule, that says "only talk to friends". It helps to reduce coupling between classes or objects. See also the references: Andrew Hunt, David Thomas, and Ward Cunningham. The Pragmatic Programmer. From Journeyman to Master. Addison-Wesley Longman, Amsterdam, October 1999.; K.J. Lieberherr and I.M. Holland. Assuring good style for object-oriented programs. Software, IEEE, 6(5):38–48, 1989.; http://www.ccs.neu.edu/home/lieber/LoD.html; http://en.wikipedia.org/wiki/Law_of_Demeter

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.coupling.LawOfDemeterRule

Example(s):

public class Foo {
    /**
     * This example will result in two violations.
     */
    public void example(Bar b) {
        // this method call is ok, as b is a parameter of "example"
        C c = b.getC();
        
        // this method call is a violation, as we are using c, which we got from B.
        // We should ask b directly instead, e.g. "b.doItOnC();"
        c.doIt();
        
        // this is also a violation, just expressed differently as a method chain without temporary variables.
        b.getC().doIt();
        
        // a constructor call, not a method call.
        D d = new D();
        // this method call is ok, because we have create the new instance of D locally.
        d.doSomethingElse(); 
    }
}