Eliminate irrelevant classes

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(New page: '''Riel's heuristic #3.7''': Eliminate irrelevant classes from your design. An irrelevant class adds no meaningful behaviour to your system for the domain you are modeling. This can apply...)
 
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett)
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Riel's heuristic #3.7''': Eliminate irrelevant classes from your design.
+
:''Eliminate irrelevant classes from your design.'' --Riel's Heuristic 3.7, [[Arthur Riel 1996]]
  
 
An irrelevant class adds no meaningful behaviour to your system for the domain you are modeling. This can apply to subclasses that inherit from a base class but do not add any functionality, which ties in with Heuristic 5.7: [[Avoid concrete base classes]]. Irrelevant classes generally have no other methods except getters, setters, and print functions. Getters and setters are not defined as meaningful behaviour because they only deal with descriptive attributes, they do not define behaviour for the domain. An exception to the getters and setters rule are sensor and transducer classes. A transducer is a device that converts an input signal of one form into an output signal of another form. A meaningful behaviour of a sensor is to get, and a meaningful behaviour of a transducer is to set.
 
An irrelevant class adds no meaningful behaviour to your system for the domain you are modeling. This can apply to subclasses that inherit from a base class but do not add any functionality, which ties in with Heuristic 5.7: [[Avoid concrete base classes]]. Irrelevant classes generally have no other methods except getters, setters, and print functions. Getters and setters are not defined as meaningful behaviour because they only deal with descriptive attributes, they do not define behaviour for the domain. An exception to the getters and setters rule are sensor and transducer classes. A transducer is a device that converts an input signal of one form into an output signal of another form. A meaningful behaviour of a sensor is to get, and a meaningful behaviour of a transducer is to set.
  
 
A typical way to eliminate such classes is to demote the class to an attribute of another class. You do not necessarily have to completely remove the information from the design.
 
A typical way to eliminate such classes is to demote the class to an attribute of another class. You do not necessarily have to completely remove the information from the design.
 +
==Conflicts==
 +
===Concrete base classes===
 +
Riel's Heuristic #5.7 [[Avoid concrete base classes]] can conflict with this heuristic. Imagine we have an application with a class called ''Toilet'':
 +
public class Toilet
 +
{
 +
    //Constructor
 +
    public Toilet {...}
 +
    //Methods
 +
    public void RaiseLid() {...}
 +
    public void LowerLid() {...}
 +
    public void Flush() {...}
 +
}
 +
Now, lets say we need to extend the ''Toilet'' class to model a ''Portaloo'':
 +
public class Portaloo : Toilet
 +
{
 +
    //Constructor
 +
    public Portaloo() : base() {...}
 +
    //Methods
 +
    public void TipOver() {...}
 +
}
 +
Here we have a problem: By allowing ''Portaloo'' to extend ''Toilet'', we have broken [[Avoid concrete base classes]]. That's easy to fix; we can make an abstract ''Toilet'' e.g. ''ToiletBase'', and inherit behaviours from that:
 +
public abstract class ToiletBase
 +
{
 +
    //Methods
 +
    public void RaiseLid() {...}
 +
    public void LowerLid() {...}
 +
    public void Flush() {...}
 +
}
 +
Now our ''Toilet'' inherits all its behaviours from ''ToiletBase'':
 +
public class Toilet : ToiletBase
 +
{
 +
    //Constructor
 +
    public Toilet {...}
 +
}
 +
''Portaloo'' extends the behaviours of ''ToiletBase'':
 +
public class Portaloo : ToiletBase
 +
{
 +
    //Constructor
 +
    public Portaloo() {...}
 +
    //Methods
 +
    public void TipOver() {...}
 +
}
  
== See also ==
+
Unfortunately, by allowing ''Toilet'' to inherit ''all'' its behaviours from ''ToiletBase'', we have created a degenerate or irrelevant class. We have, therefore, broken [[Eliminate irrelevant classes]].
* [[Riel's heuristics]]
+
 
 +
==Conflicts with==
 
* [[Avoid concrete base classes]]
 
* [[Avoid concrete base classes]]
 +
* [[Abstract classes should be base classes]]
 +
 +
[[Category:Riel's heuristics]]

Latest revision as of 03:08, 25 November 2010

Eliminate irrelevant classes from your design. --Riel's Heuristic 3.7, Arthur Riel 1996

An irrelevant class adds no meaningful behaviour to your system for the domain you are modeling. This can apply to subclasses that inherit from a base class but do not add any functionality, which ties in with Heuristic 5.7: Avoid concrete base classes. Irrelevant classes generally have no other methods except getters, setters, and print functions. Getters and setters are not defined as meaningful behaviour because they only deal with descriptive attributes, they do not define behaviour for the domain. An exception to the getters and setters rule are sensor and transducer classes. A transducer is a device that converts an input signal of one form into an output signal of another form. A meaningful behaviour of a sensor is to get, and a meaningful behaviour of a transducer is to set.

A typical way to eliminate such classes is to demote the class to an attribute of another class. You do not necessarily have to completely remove the information from the design.

Conflicts

Concrete base classes

Riel's Heuristic #5.7 Avoid concrete base classes can conflict with this heuristic. Imagine we have an application with a class called Toilet:

public class Toilet
{
   //Constructor
   public Toilet {...}
   //Methods
   public void RaiseLid() {...}
   public void LowerLid() {...}
   public void Flush() {...}
}

Now, lets say we need to extend the Toilet class to model a Portaloo:

public class Portaloo : Toilet
{
   //Constructor
   public Portaloo() : base() {...}
   //Methods
   public void TipOver() {...}
}

Here we have a problem: By allowing Portaloo to extend Toilet, we have broken Avoid concrete base classes. That's easy to fix; we can make an abstract Toilet e.g. ToiletBase, and inherit behaviours from that:

public abstract class ToiletBase
{
   //Methods
   public void RaiseLid() {...}
   public void LowerLid() {...}
   public void Flush() {...}
}

Now our Toilet inherits all its behaviours from ToiletBase:

public class Toilet : ToiletBase
{
   //Constructor
   public Toilet {...}
}

Portaloo extends the behaviours of ToiletBase:

public class Portaloo : ToiletBase
{
   //Constructor
   public Portaloo() {...}
   //Methods
   public void TipOver() {...}
}

Unfortunately, by allowing Toilet to inherit all its behaviours from ToiletBase, we have created a degenerate or irrelevant class. We have, therefore, broken Eliminate irrelevant classes.

Conflicts with

Personal tools