Identify message layers pattern

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
(Fixed spelling/code)
m
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
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.  
+
This axiom is contained in [[PLoP 1995|Pattern Languages of Program Design]] and republished in [[Ken Auer 1995]].  
  
====What to do====
+
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.
  
'''"'''Identify a small subset of the abstract state and behavoiur methods which all other methods can rely on as kernel methods'''"'''
+
====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:
  
Identify methods that can be implemented by referring to these methods and using these methods minimise the amount of concrete state that your class requires.
+
    public class circle {
 
+
====Watch out for====
+
Be careful not to create circular dependencies; for example, consider a class ''circle'':
+
public class circle{
+
+
 
         public double getRadius(){
 
         public double getRadius(){
 
                       return getDiameter() * 2;
 
                       return getDiameter() * 2;
Line 18: Line 14:
 
                       return GetRadius()/2;
 
                       return GetRadius()/2;
 
           }
 
           }
}  
+
    }
 +
 
 +
There is also the risk of grossly inefficient convoluted code. 
 +
 
 +
====The solution====
  
Watch out for creating overly complex and inefficient code.
+
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 ==
 
== See also ==
* [[Ken Auer 1995]]
+
*[[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).

See also

Personal tools