To new or not to new
Colin Putney
cputney at wiresong.ca
Fri Sep 28 06:27:39 UTC 2007
On Sep 27, 2007, at 9:58 PM, Alejandro Martínez wrote:
> In which case do you create specialized class message for
> instantiating an object?
>
> I think two factors are fundamental:
> 1) You want to enforce correcteness of your objects by making sure
> they are complete, so you "minimize" #new and provide specialized
> messages for creation.
> 2) You do not want to enforce anything until real usage experience
> shows you which messages you must "promote" to the class side.
>
> My personal view is 2) would be more humble at first, but since
> this is a question so dependent of the domain you're implementing
> and your knowledge about it, I'd like to know which patterns or
> approaches have you seen or taken through the years.
Hi Alejandro,
In my experience, the thing to be thinking about is clarity. Will
creating a specialized instance-creation method make your code easier
to understand? If so, do it.
Take the class Semaphore as an example. #forMutualExclusion is a
great method. The implementation is pretty trivial, you could replace
all the senders with "Semaphore new signal" without complicating the
code much. But you'd have a huge loss in terms of clarity. With
"Semaphore forMutualExclusion" it's obvious what you're doing, so
much so that you don't even have to remember the details of how to
use semaphores as mutexes. #forMutualExclusion and #critical: are all
you need.
Don't worry about 1). You can't "enforce" anything in Smalltalk
anyway, and if you could it would just make life difficult for the
next guy who has to deal with the code - and chances are good that
guy is you. Instead, try to make life easier for the users of the code.
Don't worry about 2) either. If experience shows you a better way to
initialize objects of a particular class, use it. You can have more
than one instance-creation method if you want, or update all the
senders of the old method to use the new one. Don't worry at all
about doing one thing and then changing your mind later.
One final thought. I find that I like to organize an object's state
according to its life-cycle. If there are certain variables that are
set when an object is created and are never changed over its
lifetime, I create a specific constructor for those variables, and a
single initializer method something like #setFoo:bar:baz: on the
instance side. I might have getters for those ivars, but almost never
have setters. This is the kind of that often forms the "identity" of
the object, so having specialized constructor and initializer methods
helps make that clear.
On the other hand, I usually don't include volatile state in
specialized constructors. Instead, I create both getters and setters,
possibly with lazy initialization, and leave it to the users to
supply that volatile state. Combining these patterns might yield
something like this:
(House atAddress: '123 Main St.')
color: Color blue;
bedrooms: 3;
yourself
The address of the house won't change, but it might get a new coat of
paint, or an addition. These aren't hard and fast rules, of course,
but habits that I seem to follow.
Colin
More information about the Squeak-dev
mailing list
|