Answered by:
My Method Parameter Dilema

Question
-
I always come to a halt when creating classes. I'm fairly intermediate to architecture so bare with me. Here's my dilema. I come to a point eventually in a class where I have to ask myself, "Does this method need parameters when I can just get what I need from the class's property or private backing field?".
Now for public methods, obviously you should most likely have parameters because someone's going to be consuming your class and using these methods whether they're in an instance class or static class. That debate is not about public methods because that is obvious to me. That if you have a public method(s) inside your class, even though lets say you can get one of the values you need from a property or private field in that class instead of requiring a param to that method and using the param, you should still require params and use the params or at least don't count them out when you can specify some params. At least this is how I view public methods because who knows how someone else might use that method and they need to know what needs to be passed and they need to pass the actual data to the method as they are outside your class.
The issue comes when for example I'm creating and using private methods or something of that sort. Lets say I create a custom control (.cs). Its job is to run a bunch of methods that I've broken out the logic for this control and create some strings of HTML to output to the browser. Well, I create a property that is public so that whoever is using this control can feed it a certain object. And that certain object is what half of the methods in my class use to help generate that HTML. Because it's a property, any of the methods in my custom class can use it. So it completely bypasses any need to create parameters in some of those methods because I can just get it form the property. But then I get to a point where I'm creating an awful lot of parameterless methods because I'm getting objects from the backing fields or combination of backing fields and properties. Or I might be just getting them from a few propewhen I am able to get what I need other ways inside this class? But then something says to you no, that's bad man, you do need parameters once in a while dude...at least a combo of parameters and using some backing fields or properties in your method, etc. but don't always discount parameters even if those params might be some internals passed to it (fields or properties). But then again if I'm gonna be passing internals as params where's the fine line between just accessing and using those fields or properties not thorugh the method as params but directly inside the method itself.
But that bothers me because then I question why I need method parameters in cases where I can get the value elsewhere.
Can someone explain the fine line here and help me come to a conclusion on the line between using a lot of backing fields in your methods or properties rather than some params you specify in the methods..even though some of those params may still be passed a value from a backing field or property when another method calls it?
I hope this makes any incling of sense but I can't be the only one who comes across this dilema. Maybe I'm the only one who thinks about this sh** and I over think I don't know. But the main problem I have personally with OOP is that there are so many damn ways to get what you need (constructor, property, backing field, method).
C# Web Developer- Edited by NoEgo Tuesday, July 14, 2009 12:56 AM
Tuesday, July 14, 2009 12:49 AM
Answers
-
If your method already has access to a value it needs, than don't pass it. Pretty simple rule really.
If your concern is that you are writing too many methods, that is a bit more gray. Obviously if your method has been factored out because it is called in a loop or called from multiple locations, than it belongs in a method. But what about having a bunch of method calls just for the sake of code clarity:
void Foo()
{
Initialize();
Inspect();
Manipulate();
Convert();
}
That's the gray bit. Would Foo benefit from unrolling those method calls inline? Of course, very, very slightly, after all it takes extra cycles to make a method call. But what if those methods are large by themselves? That makes reading Foo quite a bit more difficult. One of the principles of OOP is code clarity. If it costs a handful of cycles (at 3.2 billion per second) more to make your code more readable, than I'm all for it (except in the most extreme performance-heavy case, in which case you would not be writing OO code at all, let alone garbage collected, runtime checked code).
There are much more interesting things you could be spending your time sweating over, like object coupling, multi-threading, fast, efficient, in-place stable sort algorithms in C#, etc.- Marked as answer by NoEgo Wednesday, July 15, 2009 1:19 AM
Tuesday, July 14, 2009 1:25 AM
All replies
-
If your method already has access to a value it needs, than don't pass it. Pretty simple rule really.
If your concern is that you are writing too many methods, that is a bit more gray. Obviously if your method has been factored out because it is called in a loop or called from multiple locations, than it belongs in a method. But what about having a bunch of method calls just for the sake of code clarity:
void Foo()
{
Initialize();
Inspect();
Manipulate();
Convert();
}
That's the gray bit. Would Foo benefit from unrolling those method calls inline? Of course, very, very slightly, after all it takes extra cycles to make a method call. But what if those methods are large by themselves? That makes reading Foo quite a bit more difficult. One of the principles of OOP is code clarity. If it costs a handful of cycles (at 3.2 billion per second) more to make your code more readable, than I'm all for it (except in the most extreme performance-heavy case, in which case you would not be writing OO code at all, let alone garbage collected, runtime checked code).
There are much more interesting things you could be spending your time sweating over, like object coupling, multi-threading, fast, efficient, in-place stable sort algorithms in C#, etc.- Marked as answer by NoEgo Wednesday, July 15, 2009 1:19 AM
Tuesday, July 14, 2009 1:25 AM -
Hi – I think my information might be helpful too.
Dealing with classes, constructors and methods isn’t easy if you are a beginner. However, depending on what you’re doing and what you want to benefit from that class later.
So as you can see, it all (or mostly) depends on what you’re planning to do, like: What will this class do? Etc.C# code-snippet:
==========================================================================================
//This is our class.
class Disk
{
//This is our constructor.
public Disk(string diskLetter)
{
//We have a parameter,
//which is required.
}//This is a private method.
private void GetDisk()
{
}
public double ToDouble(int i)
{
double d = Convert.ToDouble(i);
return d;
}
}
==========================================================================================
And here is a demonstration:
Figure A: Some code.
It depends on what you method will do?
I hope this information was helpful...
Have a nice day...
Best regards,
Fisnik
Coder24.com- Proposed as answer by Eric Da Programmer Tuesday, July 14, 2009 4:32 PM
Tuesday, July 14, 2009 7:04 AM -
>>>If your concern is that you are writing too many methods, that is a bit more gray
no, I'm not worried about that. I was worried about the bulk of my methods having no params in the class I'm creating.
C# Web DeveloperWednesday, July 15, 2009 1:18 AM