Eliminate irrelevant classes
m (Reverted edits by Ebybymic (Talk); changed back to last version by Stephen Fitchett) |
|||
(2 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | '''Riel's | + | :''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. | ||
Line 53: | Line 53: | ||
* [[Abstract classes should be 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.