[OSM-dev] Josm-patches and osm-lib was:OSM Date Formats

Brent Easton b.easton at exemail.com.au
Wed Oct 3 13:18:46 BST 2007



*********** REPLY SEPARATOR  ***********

On 3/10/2007 at 10:39 AM Martijn van Oosterhout  wrote:

>On 10/2/07, Shaun McDonald <shaun at shaunmcdonald.me.uk> wrote:
>> Having public parameters is completely against everything I've been
>> taught in my 4 year Computer Science degree. If you have public
>> getters and setters for all required properties then there is nothing
>> that you cannot do, that you can do with public properties. There are
>> often properties that you don't want any old person to come along and
>> modify, thus the use of getters and setters.
>
>If you don't want people to use them then you declare them private.
>There's not really any difference between a public member and a pair
>of getters/setters for a private member.

Well, actually, there is a large difference Martin. One of the basic tenets of OOP is 'information hiding' where the lower level data structures are hidden from the higher level parts of the program that use them. 

Using a public member forces the higher level routines to have to 'know' about the details of the implementation of the lower level. If you suddenly decide to swap out structure A with indexed structure B, you can happily do this and just update the getter/setters, knowing that all of the code that has already been written is accessing the information through the getter/setters and other public interface routines and will continue to work without change. On the other hand, having plugins access public members directly means that when you make changes, you have to go back and modify and recompile all of the plugins. 

That's crazy, it is exactly one of the problems that OOP was designed to overcome. By short-circuiting that process, you are just adding additional industrial sized quantities of meaningless busy-work to the on-going maintenance of the project.

Actually, in a public development project like this, private is a bad choice anyway as it can make it very difficuly to subclass classes. protected is a much better choice, with public interface routines.

Regards,
Brent.






____________________________________________________________
Brent Easton                       
Analyst/Programmer                               
University of Western Sydney                                   
Email: b.easton at uws.edu.au





More information about the dev mailing list