immutable objects/modeling values 
Author Message
 immutable objects/modeling values

Hello!

I'm writing my diploma thesis on values in object-oriented programming
languages. For example, it is not allowed to modify a value: think how awkward
it would be to have a value '2' turn into a value '3'!
As I have read, it is common practice in Smalltalk to model values as
immutable objects. Those are objects whose state cannot be changed.
Does by chance anybody have experience with this concept? Do you know if there
is any literature treating modeling of values in Smalltalk?
Also: does anybody have information how enumeration types are modeled in
Smalltalk?

Help thoroughly appreciated

Martin Fuerter



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values

Quote:
> Does by chance anybody have experience with this concept?

Yes, when an object is required with no methods for changing its value.

Quote:
> Do you know if there is any literature treating modeling of values in

Smalltalk?
Please follow the link:
http://c2.com/cgi/wiki?ValueObjectsShouldBeImmutable

--
Ankur Agarwal
Dynamic Consulting
http://www.dynamicresources.com

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values


Quote:
> Also: does anybody have information how enumeration types are modeled
in
> Smalltalk?

Enumeration types can be done through a Dictionary.
In Smalltalk, pool dictionaries act like enumeration types for
common enumerations, like print control characters, etc.

  enumDictionary:=(Dictionary new:10)
                    at:#red put:876;
                    at:#blue put:1234;
                    at:#green put:5476;
                    yourself.

  enumValue:=enumDictionary at:#red.

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values
Martin,

check out: http://www.jvalue.org/papers/ubilab-tr-1998-10-1.html

On this web site you will also find a value object framework for Java
(JValue).

If you understand German then paragraph 3.2.8 in the following book
might also be of interest:
Das objektorientierte Konstruktionshandbuch. Nach dem Werkzeug- und
Materialansatz
http://www.amazon.de/exec/obidos/ASIN/3932588053/qid=972461800/sr=1-3...

Dani
--
http://www.acm.org/~daniel.megert



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values


[snip]

Quote:
> Also: does anybody have information how enumeration types are modeled
> in Smalltalk?

I implement enumeration using symbols (instances of class Symbol). In
usual matter it is just a set of common instances used across an
application with some class methods for access (to achieve
consistency), e.g.

MyClass class>>#partnerType

    ^#Partner.

MyClass class>>#clientType

    ^#Client.

and so on.

The values are then referenced using these methods, e.g.

    self customerType = MyClass clientType ifTrue: [...].
    ...

I have seen an implementation using class hierarchy: an abstract class
has been defined and all enumeration types have been derived from it
using inheritance, e.g.

AbstractCustomer
    subclass: Partner;
    subclass: Client;

The solution works rather nice when you just need some kind of
identifier, like in the case of symbols, of course if you do not care
about the memory overhead here. The
environment support for creating/maintaining classes helps, too. It
starts to look rather ugly when there is a need to provide some
behavior in your "types" - you implement it
on the class side.
I personally do not like this approach. Somehow it hurts my senses -
class has been provided for other reasons in the system :-).

The third solution I apply where there is a need to provide some
behavior in my "enums":
- define a class,
- provide a class side collection for storing "enums",
- fill the collection with instances representing required types,
- provide the class with accessing methods.

The solution has been well described in Martin Fowler's "Refactoring":
the "Replace Type Code with Class" refactoring method. It is explained
using Java, but the idea is the
same for Smalltalk too.

Regards, Jaroslaw.

Sent via Deja.com http://www.deja.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values
In most cases where I'd use enumerations in C, I find there's a set of
classes somewhere struggling to get out.  In particular, if I start
writing things like this:

Quote:

>     self customerType = MyClass clientType ifTrue: [...].
>     ...

I'd look to see whether there shouldn't just be a Client class.  I
suspect you'll wind up with a hierarchy like:

Quote:
> AbstractCustomer
>     subclass: Partner;
>     subclass: Client;

with polymorphism replacing the enumeration testing.

--

David
http://www.davidlong.org/



Wed, 18 Jun 1902 08:00:00 GMT  
 immutable objects/modeling values


Quote:
> In most cases where I'd use enumerations in C, I find there's a set
> of classes somewhere struggling to get out.

This is exactly what the third approach is all about.

Quote:
> In particular, if I start writing things like this:


> >     self customerType = MyClass clientType ifTrue: [...].
> >     ...

> I'd look to see whether there shouldn't just be a Client class.  I
> suspect you'll wind up with a hierarchy like:

> > AbstractCustomer
> >     subclass: Partner;
> >     subclass: Client;

> with polymorphism replacing the enumeration testing.

Sure, sure, sure. It was just an example :-).

There are plenty of places where state information is required and has
to be coded one way or another. One can code it using classes and then
use polymorphism instead of case statements (I sow it being called
Behavi{*filter*}Case), but you can use symbols as well. The question to ask
here is: what the special class, or rather its instance, is going to
do? If there is not much to say about it, it is the place for Symbol.

One could, of course, have classes and even use Visitor Design Pattern
to get rid of case statements and related parts of the algorithm, but
then one can be faced with:

    "Are design patterns really helpful ?

    I have found that they complicates the things sometimes."

[sorry Ankur, but I could not stand the temptation... :-)]

So, this is rather another story: "how to...".

Regards, Jaroslaw.

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Object models, Domain models, Application models, and MVC?

2. Object models, Domain models, Application models, and MVC?

3. OOPSLA Workshop: Modeling with Objects and Values

4. OOPSLA Workshop: Modeling with Objects and Values

5. OOPSLA Workshop: Modeling with Objects and Values

6. OOPSLA Workshop: Modeling with Objects and Values

7. OOPSLA Workshop: Modeling with Objects and Values

8. OOPSLA Workshop: Modeling with Objects and Values

9. OOPSLA Workshop: Modeling with Objects and Values

10. OOPSLA Workshop: Modeling with Objects and Values

11. Identity Vs Immutable Objects

12. How best to implement immutable objects?

 

 
Powered by phpBB® Forum Software