About KCP and automatic initialize
Richard Staehli
rastaehli at mac.com
Fri Sep 12 18:50:20 UTC 2003
Avi's description of initialization conventions looks like a
combination of design patterns.
On Vendredi, sep 12, 2003, at 04:55 Europe/Zurich, Avi Bryant wrote:
> The only formal conventions I know of for dealing with this problem
> actually come not from Smalltalk but from the NeXT FoundationKit for
> Objective-C.
>
> There is some description of these conventions in the documentation of
> #init and #new on NSObject:
>
> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
> ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/init
>
> http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
> ObjC_classic/Classes/NSObject.html#//apple_ref/doc/uid/20000050/new
(My definitions for these patterns; apologies if someone else has used
these names in a different way.)
Pattern 1: Canonical Initializer
Problem: How to establish a single method for an object that
initializes to a well defined state. Users with minimal training
should be able to discover this method and use it reliably to
initialize the object.
Solution: Require that every object have a method named with the
prefix 'initCanonical' and taking a set of arguments that completely
define the state of the object. If the object inherits state from a
superclass, the 'initCanonical' method is responsible for initializing
this state and this is easily accomplished by calling the superclass'
canonical initializer.
Pattern 2: Convenience Method
Problem: Commonly repeated sequences of code increase the chance of
error and obscure more important aspects.
Solution: Define a method that aggregates the repeated sequence into a
single message send. For example, if a canonical initializer is
frequently called with the same value for many of its arguments,
replace these calls with a call to a convenience method that
encapsulates these invariant values. The invocation of the convenience
method is syntactically shorter because it takes only the arguments
that vary.
Pattern 3: Default Constructor
Problem: Users frequently need to obtain new objects with well defined
state, but cannot be expected to understand how to reliably initialize
that state.
Solution: Require every class to have a method named 'defaultNew' that
takes no arguments, but that creates a basic new instance and calls the
canonical initializer for the object with default arguments.
It would seem to be a good idea to agree on a "canonical initializer"
prefix and "default constructor" name for squeak. It is tempting to
view "initialize" as the former and "new" as the latter, but this
choice would imply that we need to correct lots of code. Recent
discussion suggests that there is too much opposition to redefining
these common method names. Choosing new names means that we have to
write a lot of new and duplicated code wherever we want to take
advantage of these patterns.
Richard Staehli
More information about the Squeak-dev
mailing list
|