Hello all,
I would like to know what is the practical difference between instance and class in the System Browser. Based on the Abstract Factory example from Alpert's 'Desgin Patterns' book:
1) Not using class:
Object subclass: #CarAssembler instanceVariableNames: 'factory'
factory: aCarFactory factory := aCarFactory.
And in the workspace:
assembler := CarAssembler new factory: RenaultFactory new.
car := assembler assembleCar.
Works fine.
2) Using class:
The book example actually uses:
Object subclass: #CarAssembler instanceVariableNames: 'factory'
CarAssembler class>> using aCarFactory
And then in the workspace:
assembler := CarAssembler using: RenaultFactory new.
car := assembler assembleCar.
That also works fine.
I see it as a semantic difference only. There must be more than that. The class approach would nevertheless have an instance variable of the name 'factory' in which the wished factory object will be found. That variable is here initialized to a RenaultFactory in both cases. What are the pros and cons of using or not using the class approach ?
Thanks,
Al
"lanas" == lanas lanas@securenet.net writes:
lanas> I would like to know what is the practical difference between lanas> instance and class in the System Browser. Based on the Abstract lanas> Factory example from Alpert's 'Desgin Patterns' book:
A class is always a singleton. There is only one class named Car in the system. However, there can be many car instances, usually created by sending "new" to "Car".
In the Car class, you'd hold information collectively about all cars, such as the default specifications or number of cars produced.
In each car instance, you'd hold information about a specific car, like its color or owner.
Does that help?
Le Dimanche, 31 Janvier 2010 15:13:50 -0800, merlyn@stonehenge.com (Randal L. Schwartz) a écrit :
A class is always a singleton. There is only one class named Car in the system. However, there can be many car instances, usually created by sending "new" to "Car".
In the Car class, you'd hold information collectively about all cars, such as the default specifications or number of cars produced.
In each car instance, you'd hold information about a specific car, like its color or owner.
Thanks for pointing that out. In the book's example though, the variable is declared as instance variable. To go along with class variables holding information for all instances, it should instead be declared as class variable isn't it ? (Although it does work like this).
Object subclass: #CarAssembler instanceVariableNames: 'factory' classVariableNames: ''
CarAssembler class>>using: aCarFactory ^self new factory: aCarFactory
That is, if one thinks that a single car factory should be shared amongst all instances of CarAssembler. I think not and I would make it local to each object instance.
Al
On Mon, Feb 1, 2010 at 01:22, lanas lanas@securenet.net wrote:
CarAssembler class>>using: aCarFactory ^self new factory: aCarFactory
I think this a pattern for instance creation.
The point is that you can clearly see what it takes to create a instance of CarAssembler, namely, a CarFactory.
Notice that: self new "will create the instance" factory: a CarFactory "is storing aCarFactory in the instance, not the class"
Hi lanas
Your instincts are correct.
The 'factory' variable should belong to the instance.
The important thing about messages is trying to keep strait who they are going to.
In this case the #factory message is sent to an instance of CarAssembler. The message new is sent to the class usually denoted as CarAssembler class. The message #new makes an instance which the message #factory then supplys with a value.
The class is there to manufacture assemblers and to keep track of the methods they know (e.g. #factory:). The factory ivar is there to keep track of a second object which in your example was an instance of a class that assembles a particular type of car.
The message #using: is a convenience. It is sent fo CarAssembler class inorder to create an instance of a CarAssembler that will assemble a particular type of car according to its argument.
To touch on the question you asked, which was both methods work so which one is preferred. The answer is it's designer choice. In the context of an application that made only a few different instances of car assembler it might be simpler to get along with out the convenience method. If you are turning out car assemblers by the dozens then the #using: method would keep your code shorter and clearer.
Often times the answer to questions like your are "It depends."
hth,
Yours in friendship and service, --Jerome Peace
--- On Sun, 1/31/10, lanas lanas@securenet.net wrote:
From: lanas lanas@securenet.net Subject: Re: [Newbies] System Browser: instance vs. class To: beginners@lists.squeakfoundation.org Date: Sunday, January 31, 2010, 7:22 PM Le Dimanche, 31 Janvier 2010 15:13:50 -0800, merlyn@stonehenge.com (Randal L. Schwartz) a écrit :
A class is always a singleton. There is only one
class named Car
in the system. However, there can be many car
instances, usually
created by sending "new" to "Car".
In the Car class, you'd hold information collectively
about all cars,
such as the default specifications or number of cars
produced.
In each car instance, you'd hold information about a
specific car,
like its color or owner.
Thanks for pointing that out. In the book's example though, the variable is declared as instance variable. To go along with class variables holding information for all instances, it should instead be declared as class variable isn't it ? (Although it does work like this).
Object subclass: #CarAssembler instanceVariableNames: 'factory' classVariableNames: ''
CarAssembler class>>using: aCarFactory ^self new factory: aCarFactory
That is, if one thinks that a single car factory should be shared amongst all instances of CarAssembler. I think not and I would make it local to each object instance.
Al _______________________________________________ Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Alex Schenkman -
Jerome Peace -
lanas -
merlyn＠stonehenge.com