In OOP and all programming in general I know that it is a clear rule that a method should only carry out one specific task, and if another task needs to be carried out then another method should be created. My problem is this seems pointless in my situation as it is just using more code opposed to it being 1 big method.
Here are the 2 ways in which my code could be structured (one which follow standard convention, and another which doesn’t but saves code)
Scenario 1 (2 methods)
Increasing stat method
public void increaseStat(short value, string stat)
{
switch (stat)
{
case "stamina":
if (staminaCheck.Checked == true)
{
stamina += value;
staminaText.Text = Convert.ToString(stamina);
}
staminaCheck.Checked = false;
break;
//There are 5 other similar cases for different stats but to save time I removed them
}
and decreasing stat method
public void decreaseStat(short value, string stat)
{
switch (stat)
{
case "stamina":
if (staminaCheck.Checked == true)
{
stamina -= value;
staminaText.Text = Convert.ToString(stamina);
}
staminaCheck.Checked = false;
break;
//There are 5 other similar cases for different stats but to save time I removed them
}
As you can see the code is exactly the same apart from 1 operation which is + instead of – . So instead of copying all the code into another method for the sake of conventions I decided to do this
Scenario 2 (1 big method which tackles increasing and decreasing)
public void alterStat(short value, string stat, bool operator)
{
switch (stat)
{
case "stamina":
if (staminaCheck.Checked == true)
{
if (Operator == true) stamina -= value;
else stamina += value
staminaText.Text = Convert.ToString(stamina);
}
staminaCheck.Checked = false;
break;
//There are 5 other similar cases but to save time I removed them
}
This way I am adding 2 extra lines into each case by adding a simple if statement, but saving a load of code being copied.
I just want you opinions on whether this would be seen as good programming practice or not.
Thank you for your time.
From my point of view, the gain of having much less duplicated code clearly far outweighs the rule of separation of concerns, particularly when it comes to code maintenance.
A similar scenario is using an
Enumas a state flag of an object. The proper OOP way would be to model each state as a seperate class in a state-hierarchy. The downside of the latter is the code you have to write to find out what state an object has, particularly if you use a Visitor pattern (which you should when using OOP).The rule you mentioned is especially useful if it comes to the interface of a class. If it is clearer (for the user of your class) to have
IncreaseStat()andDecreaseStat()operations, instead of having a generalChangeStat(), nobody hinders you to implement aprivate ChangeStat()method which is called by the correspondingpublicmethods for increasing and decreasing a stat. This way you take both advantages: Having specific operations for specific tasks while internally there is no duplicated code.