Comments on: Not necessarily necessary http://trinisoftinc.wordpress.com/2009/06/23/not-necessarily-necessary/ JAND Blog spot Mon, 30 Nov 2009 11:30:05 +0000 http://wordpress.com/ hourly 1 By: Jose Ayerdis http://trinisoftinc.wordpress.com/2009/06/23/not-necessarily-necessary/#comment-199 Jose Ayerdis Thu, 25 Jun 2009 07:25:26 +0000 http://trinisoftinc.wordpress.com/?p=65#comment-199 You can always edit it at the end, a correction from the statement. Remember not every one read the Comments. Rule 90-9-1. www.90-9-1.com You can always edit it at the end, a correction from the statement. Remember not every one read the Comments. Rule 90-9-1. http://www.90-9-1.com

]]> By: Akintayo Olusegun http://trinisoftinc.wordpress.com/2009/06/23/not-necessarily-necessary/#comment-198 Akintayo Olusegun Thu, 25 Jun 2009 07:20:41 +0000 http://trinisoftinc.wordpress.com/?p=65#comment-198 @ Jose Ayerdis That statement is not correct, Thanks for the correction. I would have edited the post, but then your comment would make no sense anymore, so I will leave it like that. @ Jose Ayerdis That statement is not correct, Thanks for the correction. I would have edited the post, but then your comment would make no sense anymore, so I will leave it like that.

]]> By: Jose Ayerdis http://trinisoftinc.wordpress.com/2009/06/23/not-necessarily-necessary/#comment-197 Jose Ayerdis Thu, 25 Jun 2009 00:30:08 +0000 http://trinisoftinc.wordpress.com/?p=65#comment-197 "This is where I prefer scala, the default is public, unlike java where the default is private" What do you mean the default access modifier is private?? the default access modifier in java is called packaged-modifier and it work under the package level access. PD. nice post. “This is where I prefer scala, the default is public, unlike java where the default is private”

What do you mean the default access modifier is private?? the default access modifier in java is called packaged-modifier and it work under the package level access.

PD. nice post.

]]> By: Thomas Bakketun http://trinisoftinc.wordpress.com/2009/06/23/not-necessarily-necessary/#comment-194 Thomas Bakketun Wed, 24 Jun 2009 01:20:55 +0000 http://trinisoftinc.wordpress.com/?p=65#comment-194 Getter and setters are very useful for hiding implementation details that the user of an API does not have to be bothered with. However in your example the fact that the current password of a user can not be read is clearly part of the public API. Hiding the operation of generating a new password and returning it's hash violate the getter/setter idiom. Getters should always be idempotent, ie. calling the getter twice, with any other code in between, should always return the same value. Violating this idiom will sooner or later confuse some user of the API. An example of proper use of a getter would be lazy loading in a database persistense system. A query might return "hollow" objects containg just the primary key. Whenever a property getter is accessed the data is automatically loaded from the database, and possibly cached in a hidden field of the object. Please note that when an object is shared between different threads or processes, calling the same getter twice is not garanteed to return the same value. However it is still idempotent since it's not the act of calling the getter that is changing the property's value. I would caution against the use of access modifiers as a means of keeping information secret. This will only work when the untrusted code is 100% garanteed to run in a sandbox. If it's not there are many ways of getting access to a private field, eg. by using the debugging functionality of the JVM. As you correcly state, wrapper classes are need because the primitive types in Java are not objects. But why are they not? In programming languages such as Smalltalk and Lisp everything is an object. As far as I know effecieny problems related to this had been solved long before Java was created. Getter and setters are very useful for hiding implementation details that the user of an API does not have to be bothered with. However in your example the fact that the current password of a user can not be read is clearly part of the public API. Hiding the operation of generating a new password and returning it’s hash violate the getter/setter idiom. Getters should always be idempotent, ie. calling the getter twice, with any other code in between, should always return the same value. Violating this idiom will sooner or later confuse some user of the API.

An example of proper use of a getter would be lazy loading in a database persistense system. A query might return “hollow” objects containg just the primary key. Whenever a property getter is accessed the data is automatically loaded from the database, and possibly cached in a hidden field of the object.

Please note that when an object is shared between different threads or processes, calling the same getter twice is not garanteed to return the same value. However it is still idempotent since it’s not the act of calling the getter that is changing the property’s value.

I would caution against the use of access modifiers as a means of keeping information secret. This will only work when the untrusted code is 100% garanteed to run in a sandbox. If it’s not there are many ways of getting access to a private field, eg. by using the debugging functionality of the JVM.

As you correcly state, wrapper classes are need because the primitive types in Java are not objects. But why are they not? In programming languages such as Smalltalk and Lisp everything is an object. As far as I know effecieny problems related to this had been solved long before Java was created.

]]>