Passing member variables as private method arguments?
-
Should a member variable be passed to a private method in the same class as a method argument, or should the method simply call the member variable? For years, I have passed member variables to private methods in the same class as method arguments. For example, if Public method Foo() calls private method Bar(), and if Bar() uses member variable m_MyVariable, I declare the private method with the signature:
private void Bar(SomeType myVariable) { ... }Foo() calls Bar() as:this.Bar(m_MyVariable);In other words, even though Bar() could call m_MyVariable directly, I don't do it. Instead, I create a local variable within Bar() to hold the value. I've done this to keep my private methods as self-contained as possible, and to make it obvious from the method signature just what the method needs in order to do its job. Arguably, this approach makes it easier to follow the flow of control within the program. But now I'm not so sure it's such a good idea. I often end up with long method signatures with a half-dozen or more arguments, and I find that I'm passing the same member variables (typically helper objects) to every private method in a class. So, what do you think? Am I better off passing member variables to private methods as arguments, or should I simply let the methods call member variables directly? Thanks for your input. David Veeneman Foresight SystemsDavid Veeneman www.veeneman.com
-
Should a member variable be passed to a private method in the same class as a method argument, or should the method simply call the member variable? For years, I have passed member variables to private methods in the same class as method arguments. For example, if Public method Foo() calls private method Bar(), and if Bar() uses member variable m_MyVariable, I declare the private method with the signature:
private void Bar(SomeType myVariable) { ... }Foo() calls Bar() as:this.Bar(m_MyVariable);In other words, even though Bar() could call m_MyVariable directly, I don't do it. Instead, I create a local variable within Bar() to hold the value. I've done this to keep my private methods as self-contained as possible, and to make it obvious from the method signature just what the method needs in order to do its job. Arguably, this approach makes it easier to follow the flow of control within the program. But now I'm not so sure it's such a good idea. I often end up with long method signatures with a half-dozen or more arguments, and I find that I'm passing the same member variables (typically helper objects) to every private method in a class. So, what do you think? Am I better off passing member variables to private methods as arguments, or should I simply let the methods call member variables directly? Thanks for your input. David Veeneman Foresight SystemsDavid Veeneman www.veeneman.com
The whole point of member variables, is that they are there. I would pass them only if I felt I may want to pass something else to the same method at some point. I would never pass them if the code then always relied on the right variable being passed in. The idea is to write self documenting code that others can work on easily.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Should a member variable be passed to a private method in the same class as a method argument, or should the method simply call the member variable? For years, I have passed member variables to private methods in the same class as method arguments. For example, if Public method Foo() calls private method Bar(), and if Bar() uses member variable m_MyVariable, I declare the private method with the signature:
private void Bar(SomeType myVariable) { ... }Foo() calls Bar() as:this.Bar(m_MyVariable);In other words, even though Bar() could call m_MyVariable directly, I don't do it. Instead, I create a local variable within Bar() to hold the value. I've done this to keep my private methods as self-contained as possible, and to make it obvious from the method signature just what the method needs in order to do its job. Arguably, this approach makes it easier to follow the flow of control within the program. But now I'm not so sure it's such a good idea. I often end up with long method signatures with a half-dozen or more arguments, and I find that I'm passing the same member variables (typically helper objects) to every private method in a class. So, what do you think? Am I better off passing member variables to private methods as arguments, or should I simply let the methods call member variables directly? Thanks for your input. David Veeneman Foresight SystemsDavid Veeneman www.veeneman.com
I'd say you're approach is more "procedural programming" oriented than OO oriented. While your approach has its advantages, I generally prefer to let the private methods be intelligent. My public methods usually do only parameter validation and simple state manipulation and let the private methods handle the heavy work. Private methods "hide" how they accomplish the job - which implies that private methods directly deal with member variables. Have you tried running one of those code analysis tools (FxCop, VS 2005's Code Analyzer)? I distinctly remember one of them suggesting that methods defined in your style be made static. And it makes sense too, they don't need to interact with the state of the object.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
I'd say you're approach is more "procedural programming" oriented than OO oriented. While your approach has its advantages, I generally prefer to let the private methods be intelligent. My public methods usually do only parameter validation and simple state manipulation and let the private methods handle the heavy work. Private methods "hide" how they accomplish the job - which implies that private methods directly deal with member variables. Have you tried running one of those code analysis tools (FxCop, VS 2005's Code Analyzer)? I distinctly remember one of them suggesting that methods defined in your style be made static. And it makes sense too, they don't need to interact with the state of the object.
Regards Senthil [MVP - Visual C#] _____________________________ My Blog | My Articles | My Flickr | WinMacro
Thanks--that's very helpful!
David Veeneman www.veeneman.com
-
The whole point of member variables, is that they are there. I would pass them only if I felt I may want to pass something else to the same method at some point. I would never pass them if the code then always relied on the right variable being passed in. The idea is to write self documenting code that others can work on easily.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Thanks Christian--very helpful!
David Veeneman www.veeneman.com
-
Should a member variable be passed to a private method in the same class as a method argument, or should the method simply call the member variable? For years, I have passed member variables to private methods in the same class as method arguments. For example, if Public method Foo() calls private method Bar(), and if Bar() uses member variable m_MyVariable, I declare the private method with the signature:
private void Bar(SomeType myVariable) { ... }Foo() calls Bar() as:this.Bar(m_MyVariable);In other words, even though Bar() could call m_MyVariable directly, I don't do it. Instead, I create a local variable within Bar() to hold the value. I've done this to keep my private methods as self-contained as possible, and to make it obvious from the method signature just what the method needs in order to do its job. Arguably, this approach makes it easier to follow the flow of control within the program. But now I'm not so sure it's such a good idea. I often end up with long method signatures with a half-dozen or more arguments, and I find that I'm passing the same member variables (typically helper objects) to every private method in a class. So, what do you think? Am I better off passing member variables to private methods as arguments, or should I simply let the methods call member variables directly? Thanks for your input. David Veeneman Foresight SystemsDavid Veeneman www.veeneman.com
I raised this issue on comp.object. You can read my original post here[^]. Be sure to read the replies. At one point, I was using your approach and to an extra step in making my private methods static. My main reasoning is that I didn't like my private methods changing the state of the object. For example, say that a public method needs to call two private methods, one right after the other, in order to perform a task. Say that the first private method alters the state of the object. Also, say that it's possible for the second private method to fail for some reason. If the first method alters state and the second method fails, you will need to revert the state to its earlier, pre-error condition. My approach at the time was to call my private methods, passing them whatever info they needed, store the results of the methods in local variable (to the public method), and finally update the object's state once the private methods have completed. However, I have fallen out of this practise, if for no other reason than laziness. Most of my private methods can alter state and such. I'm a little uncertain, still, if this is good design.
-
I raised this issue on comp.object. You can read my original post here[^]. Be sure to read the replies. At one point, I was using your approach and to an extra step in making my private methods static. My main reasoning is that I didn't like my private methods changing the state of the object. For example, say that a public method needs to call two private methods, one right after the other, in order to perform a task. Say that the first private method alters the state of the object. Also, say that it's possible for the second private method to fail for some reason. If the first method alters state and the second method fails, you will need to revert the state to its earlier, pre-error condition. My approach at the time was to call my private methods, passing them whatever info they needed, store the results of the methods in local variable (to the public method), and finally update the object's state once the private methods have completed. However, I have fallen out of this practise, if for no other reason than laziness. Most of my private methods can alter state and such. I'm a little uncertain, still, if this is good design.
Thanks for your feedback--it's very helpful. I've gotten sold on changing to the way you are doing it now. What I found persuasive was the argument that private methods are first-class members of an object. The are only private in order to hide their workings from the outside world, not because they are somehow inferior. As such, they should have the same access to an object's state as any other method. That makes a lot of sense to me. I've just refactored a project I'm working on to remove member-variable arguments, and I think it does simplify the code and make it easier to read.
David Veeneman www.veeneman.com