|
>For your first question: In my own methods in C++ objects I change the class >variables directly inside the class rather than using my Get/Set methods. >Primarily because it is easier to maintain because someone knows what I'm >doing when I say: >MyInt = MyVar; >inside a method, but if I say: >SetInt( MyVar ); >I'm going to wonder why I didn't just use the assignment and have a look in >SetInt just to see that it's only doing an assignment. The question is a practical one -- are you likely to have MyVar be the subject of some form of inheritance? Will the apparent simple assignment becomes something else in the child? In that case, getters and setters are mandetory. If not, it is a question of clarity and maintainability. In C++, if it is a nonvirtual method, it is a completely stylistic choice since inlining can be guaranteed. Ditto in Java if the method can be made final. Otherwise, in either Java or C++, it is a little more complicated. Performance would favor the direct access with no inheritance in the picture. At some point, you are the domain expert and entitled to implement your methods' contracts with speed, clarity, and common sense. Now, in the exact example cited later on by the first note: public String rightJustify(String s, int length) { (insert your favorite code here) } and then public String rightJustify(String s) { return rightJustify(s,8); } We aren't quite dealing with object-oriented code anyway, since "s" is neither an instance variable or even a class local variable. Both are, in the end, procedural routines and all we're talking about is using signatures in a fairly standard way that is what folks used to call "C++ as a better C" (even in Java). In other words, it is basically something decided by the old-fashioned pre-object-oriented considerations. It's a valid technique and a benefit of the whole notion of "signatures" for methods. Larry W. Loen - Senior Linux, Java, and iSeries Performance Analyst Dept HP4, Rochester MN
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.