Ken Auer 1995
From CSSEMediaWiki
(Difference between revisions)
(New page: ''Reusability through self-encapsulation'', by Ken Auer, in Plop one 1995. [[http://www.cosc.canterbury.ac.nz/teaching/classes/cosc427/ReusabilityThroughSelf-Encapsulation.htm|This pa...) |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Jenny Harlow) |
||
| (14 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | ''Reusability through self-encapsulation'', by Ken Auer, in [[ | + | ''Reusability through self-encapsulation'', by [[Ken Auer]], in [[PLoP 1995]]. |
| − | + | [http://www.cosc.canterbury.ac.nz/teaching/classes/cosc427/ReusabilityThroughSelf-Encapsulation.htm This paper] provides a pattern language focused on the issue of encapsulation. It uses Smalltalk examples, but is not too hard to follow. (But note that in Smalltalk, all methods are public and all attributes are protected.) | |
== Discussion == | == Discussion == | ||
| Line 18: | Line 18: | ||
The patterns are: | The patterns are: | ||
| − | + | * [[Define classes by behavior, not state pattern]]. | |
| − | + | * [[Implement behavior with abstract state pattern]]. | |
| − | + | * [[Identify message layers pattern]]. | |
| − | + | * [[Defer identification of state variables pattern]]. | |
| − | + | * [[Encapsulate concrete state pattern]]. | |
| − | + | * [[Use lazy initialization pattern]]. | |
| − | + | * [[Define default values via explicit protocol pattern]]. | |
| − | == | + | == That's fairly interesting == |
| − | + | [http://www.c2.com/cgi/wiki?KenAuer Ken Auer's home page] on [[Ward's wiki]] says: | |
| − | + | :''Sam Adams and I were big proponents of not accessing instance variables directly. [[Ward and Kent]] always argued with us about it. So, in 1994, I saw patterns as a means to put down on paper exactly why I was right, and Ward and Kent were wrong. At the second [[Hillside Group]] meeting, I worked with [[Richard Helm]] and Bruce Anderson to discuss how the different pieces of my coding philosophy would fit together to solve all the forces I felt it solved. It was a neat exercise in pulling patterns out of ones head and into a "mostly ordered" group of patterns that together generated something much bigger. The current result of this is in the PLoP'94 proceedings, Chapter 27, "Reusability through Self Encapsulation". (By the way, I still haven't converted Ward and Kent, but they at least appreciate the benefits and I've even heard [[Kent Beck]] promoting the patterns at times, although he may not admit it publicly)... I approach Java a bit differently for a variety of reasons. As soon as I figure out and find the time to articulate them, I may produce related patterns there.'' | |
== See also == | == See also == | ||
| − | + | * [http://www.rolemodelsoftware.com/moreAboutUs/publications/articles/self-enc.php#behaviorDefinedClass Web copy] | |
| − | + | * [http://www.cosc.canterbury.ac.nz/teaching/classes/cosc427/ReusabilityThroughSelf-Encapsulation.htm Local copy] | |
| − | + | * [[PLoP 1995]] | |
| − | + | * [[Software reuse]] | |
Latest revision as of 03:17, 25 November 2010
Reusability through self-encapsulation, by Ken Auer, in PLoP 1995.
This paper provides a pattern language focused on the issue of encapsulation. It uses Smalltalk examples, but is not too hard to follow. (But note that in Smalltalk, all methods are public and all attributes are protected.)
Contents |
Discussion
Auer notes that "the benefits of encapsulation are easily ignored when exercising inheritance".
Auer's patterns are intended to enable reuse through inheritance (What Johnson and Foote 1988 called white box reuse), without hurting encapsulation.
In a similar vein to the much earlier Minimize accesses to variables, Auer says "any decision about data structure is virtually irreversable by subclasses". He advocates deferring these decisions by pushing attribute implementation decisions down the inheritance tree, and relying on Getters and setters instead.
Auer says, in effect, to use getters and setters copiously, but in a controlled way. Even private access is too loose; only one getter and one setter should ever touch a given attribute.
Encapsulation is preserved by ensuring that getter and setter methods are chosen first, as part of the interface, before thinking about how the attributes are to be implemented, or at what level of the hierarchy.
Pattern language
The patterns are:
- Define classes by behavior, not state pattern.
- Implement behavior with abstract state pattern.
- Identify message layers pattern.
- Defer identification of state variables pattern.
- Encapsulate concrete state pattern.
- Use lazy initialization pattern.
- Define default values via explicit protocol pattern.
That's fairly interesting
Ken Auer's home page on Ward's wiki says:
- Sam Adams and I were big proponents of not accessing instance variables directly. Ward and Kent always argued with us about it. So, in 1994, I saw patterns as a means to put down on paper exactly why I was right, and Ward and Kent were wrong. At the second Hillside Group meeting, I worked with Richard Helm and Bruce Anderson to discuss how the different pieces of my coding philosophy would fit together to solve all the forces I felt it solved. It was a neat exercise in pulling patterns out of ones head and into a "mostly ordered" group of patterns that together generated something much bigger. The current result of this is in the PLoP'94 proceedings, Chapter 27, "Reusability through Self Encapsulation". (By the way, I still haven't converted Ward and Kent, but they at least appreciate the benefits and I've even heard Kent Beck promoting the patterns at times, although he may not admit it publicly)... I approach Java a bit differently for a variety of reasons. As soon as I figure out and find the time to articulate them, I may produce related patterns there.
