Immutable vs Mutable

hm .. I think you should really read a little on OOP. interfaces MUST be implemented. inheritance is a petter (teorethical stuff) and interface is part of the practical stuff (not related to inheritance, though interfaces can be extended)

some articles:
http://zone.ni.com/devzone/conceptd.nsf/webmain/DCAF6FDB7A3BC02486256D4F00721675
http://java.sun.com/docs/books/tutorial/java/concepts/index.html
http://www.zib.de/visual/people/mueller/Course/Tutorial/tutorial.html
http://zone.ni.com/devzone/conceptd.nsf/webmain/0E0CE2D6F70F502386256CDA00753BAD
http://www.brpreiss.com/books/opus6/html/page588.html

the language does not count in order to understand the basics ;)

sorry for the previous post, it was ment for your other question :D

for this issue of yours, here are some links to read up:
http://www.javalobby.org/articles/immutable/index.jsp
http://www.javaworld.com/javaworld/javaqa/2002-12/01-qa-1206-immutable.html with example, in java, but that resembles C# anyway :)

I also stubbled on the wikipedia definition while searching. pretty interesting, and I think well explained:
http://en.wikipedia.org/wiki/Immutable

cheers

Hi Fernando

Did you mean

myStr = "This is a new object"

Thanks
Paul

Hi Paul;

Yes I did, sorry about that.

Fernando

Basically in an immutable object, the only time data is set within the object is when the object is created. Once created the data will never change.

mutable/immutable objects do not only apply to primitive types though.

It is quite common to have immutable objects in your own code ..

//mutable
public class Foo {
    private int bar;
    public int Bar {
        get { return bar; }
        set { bar = value; }
    }
}

//immutable
public class Foo {
    private readonly int bar;
    public int Bar {
        get { return bar; }
    }
    public Foo(int _Bar) {
        bar = _Bar;
    }
}

The major benefit by using the second in many cases is in controlling data access.

public class Container {
    private Foo foo;
    public Foo Foo {
        get { return foo; }
    }
}

using the first example (mutable object) a client can change information about our foo ex: Container.Foo.Bar = 12, in the second example the client could only change the instance of the Foo object Container.Foo = new Foo(12), since the setter is not allowed this will fail thus preventing the client from being able to change the data.

Another place this is often used is when dealing with validation. I often times have classes that require multi-step validation; by using an immutable object to hold this data I can put the validation on the create and assume anywhere I have an object that the validation has passed (This is discussed at great length in Domain Driven Design by Eric Evans, concept of a value object). It becomes quite useful in code to know that if I have an object, it is a valid object :)

Cheers,

Greg