Identify message layers pattern
Joey Scarr (Talk | contribs) m |
|||
| (5 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This axiom is contained in [[PLoP 1995|Pattern Languages of Program Design]] and republished in [[Ken Auer 1995]]. | |
| − | + | As an extension to the concept of [[Implement behavior with abstract state pattern|abstract state]], messages can be layered. This allows the class to implement even more functionality based on the already available behaviour in the class. | |
| − | + | ====The problem==== | |
| + | How to factor methods to make the class both efficient and simple to subclass. Many [[Implement behavior with abstract state pattern|abstract state]] methods can be identified in terms of others. Similarly methods that are not bound to state may also be defined in terms of other methods. However, then there is the risk of circular dependencies like that in the class circle below: | ||
| − | + | public class circle { | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
public double getRadius(){ | public double getRadius(){ | ||
| − | + | return getDiameter() * 2; | |
} | } | ||
| − | public double | + | public double getDiameter(){ |
return GetRadius()/2; | return GetRadius()/2; | ||
} | } | ||
| − | + | } | |
| + | |||
| + | There is also the risk of grossly inefficient convoluted code. | ||
| + | |||
| + | ====The solution==== | ||
| + | |||
| + | Ken Auer said: "Identify a small subset of [[Implement behavior with abstract state pattern|abstract state]] and behaviour methods which all other methods can rely on as kernel methods." [[Ken Auer 1995]]. Other methods should use these wherever possible. Concrete classes only need to implement or override the kernel methods (this has similarities to the [[Template Method|template method pattern]]). | ||
| − | + | == See also == | |
| + | *[[Ken Auer]] | ||
Latest revision as of 09:31, 18 October 2010
This axiom is contained in Pattern Languages of Program Design and republished in Ken Auer 1995.
As an extension to the concept of abstract state, messages can be layered. This allows the class to implement even more functionality based on the already available behaviour in the class.
The problem
How to factor methods to make the class both efficient and simple to subclass. Many abstract state methods can be identified in terms of others. Similarly methods that are not bound to state may also be defined in terms of other methods. However, then there is the risk of circular dependencies like that in the class circle below:
public class circle {
public double getRadius(){
return getDiameter() * 2;
}
public double getDiameter(){
return GetRadius()/2;
}
}
There is also the risk of grossly inefficient convoluted code.
The solution
Ken Auer said: "Identify a small subset of abstract state and behaviour methods which all other methods can rely on as kernel methods." Ken Auer 1995. Other methods should use these wherever possible. Concrete classes only need to implement or override the kernel methods (this has similarities to the template method pattern).
