1.13.2010

Get/Set

One thing that was bothering me for a long time is the usage of Get/Set methods for classes. Specifically because I always thought that it's silly to call a function just for getting a value I can access directly. I mean what's about the function overflow? I learned to program without inline-enabled compilers. That's why I never really understood why Get/Set functions are useful except for controlling what part of the class can be modified. I just read a whole bunch of stackoverflow comments about what the compiler optimizes and inlines and thought: "Why not?". I tend to not use Get/Set methods, because most of the structures I'm using are birectional for a lot of reasons. But thinking about which parts of my List class should be really accessible, I came to the conclusion that it's always better to create a good class interface instead of making everything accessible for all potential cases... I mean I'm a very concerned programmer. I take care of every possible NULL-pointer, wrong user input, potential bugs, etc... And somehow there's something wrong: I have all possibilities to create all kinds of bugs but I'm not interested in it. Furthermore my functions wouldn't allow something like that. So... why make everything possible, though I will only use the safest variant? Why care about making DOZENS of debug-workarounds when I can limit the interface to things I really need/use? This conclusion hits like nothing else. It's so simple. But it's yet hard for me to accept it. And it makes things much easier. Oh, nose... I feel so bad. It's always like that. I try to choose my own path for Love, Hope and Justice while getting the same results as the one who has taken the more common one. And in the end his life was more comfortable than mine. Ok, let's say I do learn a lot by walking along my own path. A lot of very interesting things he probably never was aware of (unless he read it in a book or somebody told him... the easy way of getting knowledge). But well, I've always choosen the "get your hands dirty" way when it comes to programming. Live like your enemy and you'll understand why he is like he is. And you'll probably able to defeat him with the knowledge of why he's there. I think that's the goal of learning the hard way - you're learning what makes the easy way the easy way. In terms of programming, now I really experienced why Get/Set is good and comfortable. Noone else ever gave me a good reason WHY. They all just said it's better like that. But they couldn't convey the experience of not using it. It's a totally different experience, seriously. Not using Get/Set is the full set of possible freedom. Excellent for prototypes and things you can only plan by testing and experimenting. But using Get/Set enables you, as a programmer, to reinforce your over time already well-developed sense for wrong/right interfaces (because you tried it the hard way). An emphasis on what is the good way to go. And if you did it the hard way, if you really tried to develop your own sense of what is good or not, if you finally realised how good some things are - then you've created your own style. I mean that kind of style which describes how you create your programs, how you plan, how your alghorithm design usually behaves, what a good interface for you is and such things. Your perception. Your ever-changing, inner mantra. Your path. You've just found yourself. Again.

No comments: