Making getters immutable?

[1DMF]

Hi,

I was wondering if it is possible or advised to make getters that return collections be immutable?

So as to make peforming a collection's destructive / state altering method on the returned collection not possible or at least not alter the actual objects collecion?

It seems from my testing if I create a get property to return an object attribute that is a collection, I am able to use the collection's methods to alter the state of the collection.

Should I be using a clone method in my getter code so I am passing back a clone and not the actual attribute collection?

Should I also then provide class methods for perfoming operations such as clearing the objects collection internally?

I have been speaking with the Catalyst community and one of the things they picked up on was my use of calling methods on object 'C' from object 'A'. Me.ObjectB.ObjectC.Method() or as they write it

if you have code in A which says $self->b->c->some_method then A is breaking the law of demeter, as it knows that B is implemented in terms of C.

I assume this principle is universal regardless of programming language?

Your imput is appreciated.

Regards,
1DMF.

"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads

 

[MajP]

I was wondering if it is possible or advised to make getters that return collections be immutable?

First I would think that the collection is a private class variable to your class and you do not return the collection. You have methods in your class to manipulate the collection.

If you have to return the class then you have to make a deep clone. Not easy in vba compared to .net.
In vba there is no serializing and deserializing of objects so there is no easy way to do a deep clone or even a shallow clone. You would have to write your own clone function and if it is a compound class then clone the child objects as well. Depending on the complexity of the objects in your collection this may be very easy to do or impossible. Basically here is the idea of making your own deep clone.

http://stackoverflow.com/questions/...reate-a-copy-of-a-custom-object-or-collection

 

[MajP]

BTW in vba if you are making collections of custom classes, then you should often make custom collection classes. Then the only way to create a custom object is through the custom collection. Here is an example

http://www.cpearson.com/excel/CollectionClass.aspx

 

[strongm]

Then they don't understand the 'Law' of Demeter. Container classes - which Demeter refers to as "Repetition" objects - encapsulate the implementation details of how the contained objects are stored and accessed. So assuming knowledge of members in a container isn't a structural assumption about the container, and it doesn't violate Demeter. The Demeter system considers Repetition objects as special classes of objects for which the oft-quoted normal Demeter "law" does not apply. And there are other exceptions. For example, factory classes. (And frankly the 'Law' of Demeter is really just a style guideline)

 

[1DMF]

Interesting thoughts.

I do think that either way, technically an object is meant to encapsulate state, so the state of an object can only be changed through its protocol.

Though as the methods exsposed are of a built in data type (Collection), why would it be wrong to utilise these methods that already exist for accessing that data type.

I think I need to consider outside state change consequences and if I'm simply blocking access to a method/function only to have to recreate it again just to enforce true encapsulation.

Regards,
1DMF.



"In complete darkness we are all the same, it is only our knowledge and wisdom that separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Free Dance Music Downloads