[re-post from this morning, please excuse me if this shows up twice] Hello Matt,
>Furthermore, when you make a change that impacts more than one part of >the system you're going to retest thoroughly anyway (I'd hope). You >describe the situation as if you're going to have to go line by line >through all your files and hope you find everything manually before >you throw it out into production and pray you found everything. If >making a change to your application truly turns into a horror show, >that's the fault of the design of the app, not of getters and setters. I have an object called a Widget, and i handle persistence for this object with a WidgetDAO. If or when i change something about a Widget's data (add a field, change a field's datatype, etc), calls to my DAO in the form WidgetDAO.save(myWidget) don't have to be adapted in any way because i am "pushing" an object into a method, and the composition of that object is irrelevant to the code doing the "pushing". I do, however, need to take a good long hard look at every place that calls get or set methods on Widget - Widget.getFoo(), Widget.getBar(), etc. In each of those places, i need to figure out what the code is doing and if/how it needs to be updated to take into account the new or changed Widget data. Now here's the kicker: the implementation of WidgetDAO.save() is probably full of calls to Widget.getFoo() and Widget.getBar(), so why am i making such a fuss? The reason is that it's easy to figure out that you have to change this place, because it is the implementation (body) of a method that takes instances of Widget as an argument. It's easier to figure out what you need to change because you know what that method does. (The same would apply for any methods that returned instances of Widget.) Neither of these facts is true about code that grabs a Widget from a shared scope and calls getters on it (a usage pattern common in, but not unique to, display code). Hence my point that liberal use of getters and setters, although much easier to write, leads to code that's more tightly coupled and harder to maintain, whereas adopting the "tell, don't ask" pattern, although it might well lead to writing more code, will lead to code that's easier to maintain. /t ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
