4

If I have a method that receives a value as parameter and stores it in a field for later usage, but then goes on to use that value - why would I use the parameter instead of the field?

private RailState _railState;

public void UseParameter(RailState railState)
{
    _railState = railState;
    railState.SetActive();
}

public void UseField(RailState railState)
{
    _railState = railState;
    _railState.SetActive();
}

As far as i can see, an argument for using a parameter is that if the class would be changed later and the value would only be used in that method, a decent IDE would inform me that the field is never read from and thus unnecessary.

An argument for using the field is that using the parameter won't work for value types. While this is obvious and intuitive for basic types like numbers, it might lead to surprises with unexpected structs.

However, are there other arguments - one way or the other - that I am missing?

  • If you are going to use the parameter then just SetActive() before the assignment. – paparazzo Feb 21 '17 at 14:15
2

As you pointed out, the field approach work well in all the cases (value and reference). This should be the preferred approach.

Another reason speaking in favour of the field is refactoring: if your method grows to be very complex, you could more easily split in in simpler methods when using the field approach.

The parameter could however be a better approach when handling unique operations related to the initialisation, especially in a multithreaded application, where the field could be altered by another method invoked in another thread.

Hypothetical example:

 _railstate = railstate; 
 railstate.incrementUseCount(1); // because use count of parameter is to be increased
 _railstate.activate(); // may be another thread already changed the field and decrementer use count of former field ?

So rather than dogmatism, I'd recommend to really think of the semantic: do we want to address the parameter regardless of the object state ? Or do we intend to address the object corresponding to the object state (e.g.referred by the field) ?

  • Well I literally asked for reasons why to use one over the other, so I don't know how you got to think of dogmatism. Thanks for answering though, I like your points about refactoring and threads. I can't think of anything else to consider here, but I'll wait a day before accepting an answer to see if somebody else can. – R. Schmitz Feb 21 '17 at 16:25
  • @R.Schmitz thanks for this feedback. When i mentioned dogmatism, i was not referring to your question. Sorry if I could give such impression. I just wanted to express that i restrain myself from being dogmatic on these kind of issues :-) – Christophe Feb 21 '17 at 18:15
  • 1
    In defense of @Christophe, many people are dogmatic about this type of thing. – JeffO Feb 22 '17 at 17:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.