Back when I was maintaining a C++ app, there was a struct written as a class, and everything in the struct had accessors. They were all completely simple and transparent such that you could have done away with the lot of them and accessed everything through simple public members. Nevertheless, the accessors were used everywhere. This struct was the heart of the application, so that was many many method calls. It seemed like a waste.
Then one day the requirements changed, and in some circumstances I'd have to recompute some things when others were changed. I tell you I was mighty grateful that all access went through accessors. I could go to where the class was implemented and make my changes there and nowhere else, and everything worked.
I shudder to think of the search-and-replace nightmare that would have been my workday had the elements of this struct been accessed directly throughout the program I worked on. As I said, this was the one class that was used everywhere.
I think most programs grow larger as they age. The "big program" techniques that one uses today might not be necessary today, but they often pay off in the long run. I tend to write software as if it is a little bigger than it actually is. I use strict and warnings in a two-line script. I use objects (sometimes) when a simpler data structure will do, just to collect the code related to that data structure in one place. I use set/get methods to access stuff in objects, even if they're not much more than dumb hashes (though I rarely, if ever, write those accessors myself).
I think the time lost writing big for a small program that never grows is a reasonable price for the times that I write big for a program that (as usual) does grow.
In reply to Re^7: Data Structures
by kyle
in thread Data Structures
by YYCseismic
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |