Is there anything wrong with passing state via argument?
-
I first learned C# then C. As I've been working in C a lot lately, I've had to do without classes obviously since it's not really an OOP language. I've gotten rather accustomed to passing stuff in as arguments and I'm writing a C# program right now where I've been passing "state" around via the method arguments rather than the typical storing fields/properties on the class and then accessing them from the class methods. Is there anything "wrong" about doing this? Is there anything "wrong" with not using the constructor to initialize member variables to certain values and instead just using a function in the class that calls the other business functions? E.G.
someObject myObject = new someObject();
var processResult = myObject.process(someString,Processor_Option_1);
Instead of:
someObject myObject = new someObject(someString,Processor_Option_1);
var processResult = myObject.result;
Note: Option 2 also uses class state member variables whereas 1 just passes it function-to-function as argument.
-
I first learned C# then C. As I've been working in C a lot lately, I've had to do without classes obviously since it's not really an OOP language. I've gotten rather accustomed to passing stuff in as arguments and I'm writing a C# program right now where I've been passing "state" around via the method arguments rather than the typical storing fields/properties on the class and then accessing them from the class methods. Is there anything "wrong" about doing this? Is there anything "wrong" with not using the constructor to initialize member variables to certain values and instead just using a function in the class that calls the other business functions? E.G.
someObject myObject = new someObject();
var processResult = myObject.process(someString,Processor_Option_1);
Instead of:
someObject myObject = new someObject(someString,Processor_Option_1);
var processResult = myObject.result;
Note: Option 2 also uses class state member variables whereas 1 just passes it function-to-function as argument.
No, I don't think there is anything "wrong" with your code. But the way I see it (in option 2), it is clear that your constructor is not just a constructor but also a processor, it processes the operands and then puts the result in
resultfield. If you are going to do this, then write them like,SomeObjectProcessorResult myObject = SomeObject.Process(someString,Processor_Option_1);
var res = myObject.result;This will make much more sense in C#, it does not any longer depend on the states of SomeObject (it is static), but does the same — gets input, processes and then gives out output.
public class SomeObject {
public static SomeObjectProcessorResult Process(string someString, ProcessorType option) {
// process and return
}
}public class SomeObjectProcessResult {
public Type result; // for property, Result.
}This is a near C# definition of types, while ignoring the states. Then in your first option, it is clear that the function is an instance one and will depend on states of object.
TheOnlyRealTodd wrote:
Option 2 also uses class state member variables whereas 1 just passes it function-to-function as argument.
Not so, you can ignore and from an external view I can easily think of implementation where I just process those parameters and ignore them (not save them). On the other hand, I can save those parameters in option 1 as state values. :-) That is the case in OOP, there are side effects everywhere. If you do not want to use side effects. Consider using F#, that is a functional programming language — but does have OOP. :laugh:
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
-
No, I don't think there is anything "wrong" with your code. But the way I see it (in option 2), it is clear that your constructor is not just a constructor but also a processor, it processes the operands and then puts the result in
resultfield. If you are going to do this, then write them like,SomeObjectProcessorResult myObject = SomeObject.Process(someString,Processor_Option_1);
var res = myObject.result;This will make much more sense in C#, it does not any longer depend on the states of SomeObject (it is static), but does the same — gets input, processes and then gives out output.
public class SomeObject {
public static SomeObjectProcessorResult Process(string someString, ProcessorType option) {
// process and return
}
}public class SomeObjectProcessResult {
public Type result; // for property, Result.
}This is a near C# definition of types, while ignoring the states. Then in your first option, it is clear that the function is an instance one and will depend on states of object.
TheOnlyRealTodd wrote:
Option 2 also uses class state member variables whereas 1 just passes it function-to-function as argument.
Not so, you can ignore and from an external view I can easily think of implementation where I just process those parameters and ignore them (not save them). On the other hand, I can save those parameters in option 1 as state values. :-) That is the case in OOP, there are side effects everywhere. If you do not want to use side effects. Consider using F#, that is a functional programming language — but does have OOP. :laugh:
The shit I complain about It's like there ain't a cloud in the sky and it's raining out - Eminem ~! Firewall !~
Awesome thanks for the feedback.