rulesets.java.coupling.xml Maven / Gradle / Ivy

Go to download
Show more of this group Show more artifacts with this name
Show all versions of walkmod-pmd-plugin Show documentation
Walkmod plugin to automatically fix the reported problems by PMD
There is a newer version: 2.0.9
<?xml version="1.0"?>

<ruleset name="Coupling"
    xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 http://pmd.sourceforge.net/ruleset_2_0_0.xsd">

  <description>
Rules which find instances of high or inappropriate coupling between objects and packages.
  </description>

    <rule name="CouplingBetweenObjects"
    		  since="1.04"
        message="High amount of different objects as members denotes a high coupling"
        class="net.sourceforge.pmd.lang.java.rule.coupling.CouplingBetweenObjectsRule"
          externalInfoUrl="https://pmd.github.io/pmd-5.4.1/pmd-java/rules/java/coupling.html#CouplingBetweenObjects">
    <description>
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.
    </description>
    <priority>3</priority>
    <example>
<![CDATA[
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;
   }
}
]]>
    </example>
  </rule>

  <rule name="ExcessiveImports"
    		  since="1.04"
     message="A high number of imports can indicate a high degree of coupling within an object."
     class="net.sourceforge.pmd.lang.java.rule.coupling.ExcessiveImportsRule"
          externalInfoUrl="https://pmd.github.io/pmd-5.4.1/pmd-java/rules/java/coupling.html#ExcessiveImports">
     <description>
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.
  </description>
  <priority>3</priority>
  <example>
      <![CDATA[
import blah.blah.Baz;
import blah.blah.Bif;
// 18 others from the same package elided
public class Foo {
 public void doWork() {}
}
      ]]>
  </example>
   </rule>

    <rule name="LooseCoupling"
    		 since="0.7"
          message="Avoid using implementation types like ''{0}''; use the interface instead"
          class="net.sourceforge.pmd.lang.java.rule.coupling.LooseCouplingRule"
          externalInfoUrl="https://pmd.github.io/pmd-5.4.1/pmd-java/rules/java/coupling.html#LooseCoupling">
      <description>
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.
      </description>
        <priority>3</priority>
      <example>
<![CDATA[
	// 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();
}
]]>
      </example>
    </rule>

    <rule name="LoosePackageCoupling"
    		 since="5.0"
          message="Use of ''{0}'' outside of package hierarchy ''{1}'' is not recommended; use recommended classes instead"
          class="net.sourceforge.pmd.lang.java.rule.coupling.LoosePackageCouplingRule"
          externalInfoUrl="https://pmd.github.io/pmd-5.4.1/pmd-java/rules/java/coupling.html#LoosePackageCoupling">
      <description>
Avoid using classes from the configured package hierarchy outside of the package hierarchy, 
except when using one of the configured allowed classes.
      </description>
        <priority>3</priority>
      <example>
<![CDATA[
package some.package;

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

public class Bar {
   DontUseThisClass boo = new DontUseThisClass();
}
  ]]>
      </example>
    </rule>

   <rule name="LawOfDemeter"
        language="java"
        since="5.0"
        message="Potential violation of Law of Demeter"
        class="net.sourceforge.pmd.lang.java.rule.coupling.LawOfDemeterRule"
        externalInfoUrl="https://pmd.github.io/pmd-5.4.1/pmd-java/rules/java/coupling.html#LawOfDemeter">
        
        <description>
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
        </description>
        <priority>3</priority>
        <example>
<![CDATA[
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(); 
    }
}
]]>
        </example>
    </rule>
    

 </ruleset>