We Keep Coding

How do I derive from two base constructors in a way that allows me to have default argument values?

I'm writing an exception that inherits from ArgumentOutOfRangeException and I want to write constructors that derive from the two base overloads base(string paramName) and base(string paramName, string message) but I want to provide default values for paramName in both constructors and a default value for message in the second. What is the best way to do this? (If it helps, the default value for paramName will be the same in both).
I've thought of overriding the constructor with a single constructor with a third boolean parameter to determine which constructor to call and calling that constructor, but after some testing found out that fails on so many levels.
Here is an example of what I'm trying to do:
public class TrainingSetCardinalityMismatch : ArgumentOutOfRangeException
{
public TrainingSetCardinalityMismatch(string paramName = "trainingSets") : base(paramName)
{
//code here
}
public TrainingSetCardinalityMismatch(string paramName = "trainingSets", message = "Number of training sets provided must match number of answers provided") : base(paramName, message)
{
//code here
}
}

You could call the other constructor with your default values like so
public CustomException(string paramName = "defaultName") : this(paramName, null)
{
}
public CustomException(string paramName = "defaultName", string message = "defaultMessage") : base(paramName, message)
{
}

Well from the question, I can see 2 possibilities.
You always want the message (second argument)
You sometime want the message, sometime not and sometime a different message.
In the first case, you would simply remove the definition of the first constructor. You will always have the message if you don't specify the second argument.
public class TrainingSetCardinalityMismatch : ArgumentOutOfRangeException
{
public TrainingSetCardinalityMismatch(
string paramName = "trainingSets",
message = "Number of training sets provided must match number of answers provided")
: base(paramName, message)
{
//code here
}
}
Then you could call it that ways:
// default param name + default message
throw new TrainingSetCardinalityMismatch();
// custom param, default message
throw new TrainingSetCardinalityMismatch("custom param");
// custom param, custom message
throw new TrainingSetCardinalityMismatch("custom param", "custom message");
However, it won't allows default param but with custom message.
If you want that, you have a few possibilities:
One would be to have a constant for the default message and specify it explicitly instead of the hard coded string.
Another might be to change parameter order if message need to be customized most of the time.
Another one would be to have a static functions that raise the exception.
Another one could be to set the default to null if when null is specified remplace by default value. That way, you can use an empty string if you really want no message.
Another one is to have 2 exception classes (say TrainingSetCardinalityMismatchAandTrainingSetCardinalityMismatchB`) and each one has a single constructor.
Another want would be to use an enum instead of a string when using predefined messages and then constructor with custom message would not have any default as it would be used only for specific message.
Usually, I prefer the last way and then I could use resource and a bit of code to load the appropriate string from the enum identifier which is relatively easy in C# as you can to enum_var.ToString() to get a name and use that name to load a resource by its name using the resource manager (see https://learn.microsoft.com/en-us/dotnet/api/system.resources.resourcemanager?view=netframework-4.7.2).

Why not create your own constructors and call the base ones like i've shown below
class MyArgumentOutOfRangeException : ArgumentOutOfRangeException
{
public MyArgumentOutOfRangeException(string myName):base("PlaceDefaultNamepropValue")
{
// do something with passed my name
}
public MyArgumentOutOfRangeException(string myname, string mymessage):base("PlaceDefaultNamepropValue", "PlaceDefaultMessagepropValue")
{
// do something with passed my name
// do something with passed my message
}
}
class MyOtherArgumentOutOfRangeException : ArgumentOutOfRangeException
{
public MyOtherArgumentOutOfRangeException(string myName) : this("PlaceDefaultNamepropValue",string.Empty)
{
// do something with passed my name
}
public MyOtherArgumentOutOfRangeException(string myname, string mymessage) : base("PlaceDefaultNamepropValue", "PlaceDefaultMessagepropValue")
{
// do something with passed my name
// do something with passed my message
}
}

Other than needing to define the type of message (use string message = "..."), your posted code seems to be functional and doing what you want. So I assume the core of your question is:
What is the best way to do this? .... I've thought of overriding the constructor with a single constructor with a third boolean parameter to determine which constructor to call and calling that constructor.
As a general rule, I advocate against "choose your own adventure" booleans. While they work on a technical level, there are better alternatives here.
Parameters with default values are, by definition, optional parameters. This means you're already able to decide your consumer's constructor selection based on whether the consumer passed the a non-default message value. If they didn't, then they're clearly choosing to use the first option. If they did, then they're clearly choosing the second option. They don't need to then also specify a boolean.
Does it really matter whether you don't initialize message, or instead explicitly pass null or String.empty when the consumer doesn't provide a message value? Because if not, then there's no reason to even try and distinguish between the two base constructors.
Method overloading inherently exists to give users a way to differentiate between different sets of input parameters, and each overloaded body has its own method (which you can choose to chain or not) so you have total control over what happens in which case. Your boolean would be a (IMO poor) substitute for a cleaner method overload.
CYOA booleans tend to only seem viable when you are the consumer of your own code because "I know how I designed this to work". That's often something which leads to avoiding good practice and clean coding. While it will work on a technical level, it's not a good/clean solution and it eventually teaches you bad habits. In most cases, when I use someone else's library, I expect to use the method names to decide what I want to do, not a set of boolean parameters. There are of course exception to this, but they are few and far between. When I've picked the method to use, the parameters should be easy to understand and supply, rather than forcing the user to decide separate behaviors.
Encapsulation suggests that your implementation needs to hide complexities from the consumer of your class, where possible. Which means that you're allowed to use a branching structure inside your class, but you shouldn't require the consumer to knowingly make this choice - your class exists to do this for the consumer and simplify the consumer's workload. If you pass the buck to your consumer, then what is your class' value? What does it do for you/the end user? (Note: Don't misinterpret this as an anti-IOC argument. IOC is a good thing, it just isn't really done via booleans. Using IOC, you'd be injecting behavior objects instead of boolean values).

What is the difference between these two C# class constructors?

Not really 2 constructors, rather 3 but 2 of them are overloaded.
This one was originaly on some tutorial that I watched a while back.
public Animal()
{
this.height=0;
this.weight=0;
this.name="No Name";
this.sound = "No Sound";
}
public Animal(double height, double weight, string name, string sound)
{
this.height=height;
this.weight=weight;
this.name=name;
this.sound = sound;
}
I remember this from software dev classes, so I was wondering if it made any sense to write it this way, and if not what could go wrong if this were on my code?
public Animal(double height=0, double weight=0, string name="No Name", string sound="No Sound")
{
this.height=height;
this.weight=weight;
this.name=name;
this.sound = sound;
}
Because I really don't know if I can put default values in class constructor like this.

Sure you can. And for most code you won't see a big difference (other than in the first case you'll have to supply either all of the parameters, or none).
But there is a subtle difference nevertheless, and it can bite you later on.
See, the first snippet declares a so-called default constructor and a custom one, but the second snippet only declares a custom constructor.
Here's a generic function:
public static T Create<T>()
where T : new()
{
return new T();
}
Here's what you'll get if you call Create<Animal>():
error CS0310: 'Animal' must be a non-abstract type with a public parameterless constructor in order to use it as parameter 'T' in the generic type or method 'Program.Create<T>()'
So your custom constructor does not replace a default constructor in cases where it's expected.
Same goes for reflection:
Activator.CreateInstance<Animal>();
Will result in a runtime exception:
Unhandled Exception: System.MissingMethodException: No parameterless constructor defined for this object.
So providing an accessible default constructor has also a semantic meaning. It tells an instance of your class is still meaningful when created through its default constructor, and doesn't require additional parameters. It can be used in scenarios involving serialization for instance (some serializers require a default constructor, other don't).

I would say it's mainly about communication. In the first case you either provide all the values, or nothing(..and you get the defaults). The person who wrote that code may have had a good reason for only those two options.
In the second case you are more flexible, for instance you could choose to provide only one parameter.. it could be the case that such an object would become invalid. As with most things.. it all depends

Efficient way to pass large number of argments into a constructor

I am working on a project and I have an object, upon instantiation of which, will have a large number of values (20+) passed into it. I know I could make a constructor that would take in all of the values, but I am looking for a cleaner / more efficient way to do this.
Just to put this in perspective, the object is a character in a game, new instances of which are frequently created. The values assigned are attributes which are randomly generated.
Is a constructor with a large number of arguments the best way to go? Or is there a better way to do this that I don't know about? Any advice would be greatly appreciated.
EDIT: When a new game starts, a List<Character> is created and a for loop creates 10 instances of character and adds them to the list.

You can create a call that defines your game character. have users populate that class and pass it as the argument to your class.
something like this,
public class CharecterInfo
{
public string Name {get;set;}
public int Power {get;set;}
public int Health{get;set;}
}
public class Charecter
{
public Charecter(CharecterInfo charecterInfo)
{
//import values
}
}
I would avoid using public properties, since your class could be used while it's not properly initialized (in a bad state) which is the job of the constructor. you should use a constructor and validate the input before allowing the user to continue.

If the properties have public setters, you can use the object initialization syntax, e.g.:
Character c = new FooCharacter() {
Name = "Ugly Monster",
HP = 10000,
....,
};
Edit: as pointed out in the comments, this assumes that your constructor (empty or with minimal parameters) will initialize all required properties with valid data. The initialization syntax is just syntactic sugar that sets any specified properties after the constructor has initialized the object.

This completely depends on what those arguments are... But generally, it's not a great idea to have huge parameter lists. This is because of the confusion it creates over which parameter is what. An exception to this would be where you have a variable-length argument list that takes key/value pairs, allowing you to pass your data in an undefined order.
One alternative is to make another class that represents all your arguments. You could just create an instance of this, set the relevant fields and pass that in. To extend the idea, you might break that class up into a few classes and then provide a handful of constructors that take different combinations of those.
The useful thing with this approach is that you can have a default value for any of the arguments. Normally, if you want to specify a value for something further down the argument list but use defaults for the rest, you have to fill in all the default values in between. With this approach you can use all defaults except for the values you want to specify.

You have several options:
If all of the values are required:
Stick with the large list of parameters
Create a new class which has all of these items as properties
If not all of the values are required and you can use the Builder-pattern:
This link describes the pattern in detail: http://cdmckay.org/blog/2009/07/03/joshua-blochs-builder-pattern-in-csharp/

You can make a method that returns a class instance. Perhaps even in that class itself.
Something like:
public class Character
{
public string Name;
public int Level;
static Random random = new Random();
public static Character CreateNew()
{
Character newOne = new Character();
newOne.Level = random.Next(1, 5);
newOne.Name = (random.Next(1, 2) == 1) ? "Me" : "You";
return newOne;
}
}

One possibility lies in OOAD itself. Character attributes sound like a big enough concern to be the responsibility of a distinct class with which your character class collaborates.
A quick CRC analysis of your domain may help identify one or more newly distinguished responsibilities & corresponding types that are missing presently.

Dynamically hooking up a class having different possible constructors

Let's say I have two classes that look like this:
public class ByteFilter
{
private Func <int, byte[]> readBytes;
private Action<byte[]> writeBytes;
public ByteFilter(Func <int, byte[]> readBytes, Action<byte[]> writeBytes)
{
this.readBytes = readBytes;
this.writeBytes = writeBytes;
}
}
public class PacketFilter
{
private Func<Packet> readPacket;
private Action<Packet> writePacket;
Public PacketFilter(Func<Packet> readPacket, Action<Packet> writePacket)
{
this.readBytes = readPacket;
this.writeBytes = writePacket;
}
}
Either class may be instantiated at runtime (via Activator.CreateInstance) to perform a filtering function. The read and write methods will be hooked up at runtime to methods from other classes that will provide and accept byte arrays or packets.
Within each filter is additional code that performs the filtering function:
public void Process()
{
while (!done)
{
byte[] data = ReadBytes(); // or ReadPacket()
// perform filtering on data
WriteBytes(data); // or WritePacket()
}
}
If only one of the above constructor signatures will be present in each filter, how do I determine (using Reflection) which constructor signature is present, so that I can hook up the appropriate methods at runtime?
Note: If I'm daffy and doing this the wrong way, I'd like to know that too.

Can't you do something like?
bool packetConstructor =
typeof(PacketFilter).GetConstructors()
.Any(c => c.GetParameters()
.Any(p => p.ParameterType
== typeof(Func<Packet>)));
replacing typeof(PacketFilter) with appropriate instance.

An option that has not been mentioned is to use Fasterflect, a library created to make reflection easier and faster where possible.
It also has a couple of features built on top of the core reflection capabilities, one of which is the ability to construct objects when you don't know what constructors are available.
var instance = typeof(PacketFilter).TryCreateInstance( new { Foo = "Bar" } );
There are also overloads for passing in a dictionary of named values or discrete name and value arrays. The latest code also provides extensions for constructing objects just from an ordered list of values, matching them in order to parameters by their type.
Fasterflect will automatically pick the constructor with the most matching arguments. If it's unable to use a value it'll try to set a matching property after construction. And you have the option of requiring all values to be used.
Disclaimer: I'm a contributor to the project.

You can enumerate the constructors (to get the one constructor) and then enumerate the parameters of the constructor. Since the parameters are expected to be generic types, you then need to enumerate the generic type parameters for each generic constructor parameter. Note that all of this is very hacky and I would recommend finding a better solution. Reflection is a powerful tool and using it introduces complexity; if there is a less complex solution (such as a factory pattern, perhaps), that would be preferable. It's also possible that your need to solve this particular problem reflects excessive complication in your existing design. If you simplify the original design, you may find that the technical problem goes away.

Instance initialization strategy in c#

For a class instance to work properly, some fields should be properly initialized, what's your strategy to initialize these field, what should be given through constructor, what should be given through property?
My confusion is that, if the constructor requires a long parameter list, it's hard to use, if through properties, i tend to forget to set some properties.
What's the best practice?

You must ask yourself, if your class needs that many things to be created, perhaps it is doing too much. It's a sign that you should reconsider your design, or just how much "work" the constructor is doing.
It is true that you should not be able to create an instance with invalid state; thus the constructor should take all properties you need to be in a valid state.
To a degree, it depends on your model. For example, the ORM I use has the constructor take one parameter; an ID by which it can load all the other properties. It would be annoying if I had to pass them all in (that's the job of the ORM really; to set this object up). So in that sense, you can argue you have an "invalid" object (no properties set). But you'd be wrong; what you actually have is a "blank" or "empty" object. That's not the same as invalid.
So think carefully about what it means for your object to be "invalid". I would consider it invalid if other methods took this object, and threw an exception because something wasn't set. Use this logic to determine what needs to be in the constructor, and what can be set later (by some other process).

This is always a balancing act - you don't want to have constructors that require many parameters but you also don't want to require that a user set many properties before an object is in a valid state. Unfortunately there is no real guidance here as you must use your best judgment for the situation at hand.
Many times you may need to create a composite type which has many properties and many possible configurations (e.g. System.Web.Page). Composite types tend to have simple constructors that take little or no parameters and all values must be set through properties. Composite types are high-level types that are composed of lower-level factored (or primitive) types.
Factored types tend to be simpler, contain less state, and can be completely initialized via their constructors. Examples of factored types are System.String and System.Int32. These types are very simple and tend to be the building blocks of composite types.
If your type is a factored type then try your best to allow consumers to initialize the type completely via the constructor. If your type is a composite type then it is better to offer simple constructors with little or no parameters and require that the consumer configure the instance via property setters.

Now that .NET 3.5 allows you set any property on creation, I generally restrict any constructor with parameters to situations where the instance absolutely must have a value on creation. There really isn't any other reason to add constructor overloads with parameters IMO.

I think the best thing would be to perform validation and generally try to keep constructors with no parameters as it is often a requirement for different .NET libraries.
With validation you will have to check the object's validity, but it is pretty common thing to do. Something among the lines:
public interface IValidateable {
IEnumerable<string> Validate();
}
public class Person : IValidateable {
public string Title { get; set; }
public string First { get; set; }
public string Last { get; set; }
public Address HomeAddress { get; set; }
public Person() {
HomeAddress = new Address();
}
public IEnumerable<string> Validate() {
var errors = new List<string>();
if (string.IsNullOrEmpty(First))
errors.Add("First name is required.");
// And so on...
return errors;
}
}
// Usage
var p1 = new Person();
var p2 = new Person {
First = "Dmitriy"
};
if (p1.Validate().Any()) {
// Do something with invalid object
}