I've got myself into a bit of a mess. I've got code coming from Main, through myMethod and down to OtherMethod. One of the parameters can be either an int or a string, which affects OtherMethod but none of the intervening methods.
public static void Main()
{
myMethod(number: 10);
myMethod(letters: "ten");
}
public static void myMethod(int number = 0, string letters = null)
{
//long entirely shared code with calls to:
OtherMethod(number,letters);
}
public static void OtherMethod(int number = 1, string letters = null)
{
//Lots of shared code, embedded multiple times within this code is essentially:
if (letters != null)
{
Console.WriteLine("letters!");
}
else
{
Console.WriteLine("numbers!");
}
}
OtherMethod cares about when I'm passing it int
or string
, but none of the intervening methods care. I would also find splitting OtherMethod without unnecessary code reuse very hard.
The solution I have provided works, but is probably an anti-pattern. Because, for example, a call to myMethod(10,"ten")
would silently throw 10
in the bin.
Would changing it to private mymethod(int number = 0, string = null)
called by public (int number)
and public (string letter)
for each level be a terrible idea?
I though of instead passing a class with both int and string and instructions of which to use right from the top to bottom. I suspect this is the solution. But it feels as OTT as it does OO.
My real use case is that I'm randomly generating data at the bottom of this chain and I can either provide a seed (int), or cheat and provide the data to generate (string). It occurs to me that what I'm doing may be a procedural dependency injection bodge,