Develop Reference

Validation of a C# object initialized with init-only setters

Disclaimer for re-opening
This question is about object validation of an immutable object during construction using C# 9 init-only setters (as opposed to using a constructor with verbose "boiler plate code").
C# 9 introduces an option to initialize immutable object with object initializer syntax, using init only setters:
class Immutable
{
public string Name { get; init; }
public int Value { get; init; }
}
Immutable o = new Immutable { Name = "Value1", Value = 257 };
Additionally it introduces a nice syntax to create mutated copies of an object:
var o1 = o with { Value = 65537 };
Previously the only option to create and initialize a new immutable object was to use constructor with parameters. The new option is more natural and elegant, but one important feature of constructor initialization is missing: validation. With constructor I can be sure to never create an object with invalid state.
It is possible to put validation code into init setters, but there's no way, of which I'm aware of, to provide a general validation of object state as a whole. Specifically, I don't see any way to assure in the example above that Name property will fulfill its contract to have a non-null value. As parameterless constructor is necessary to use object initializer syntax, it is possible to create an uninitialized instance:
var o = new Immutable();
in which case properties will get default values.
Question [edit]: is there any method to validate immutable object state after initialization with init setters is complete? Keep in mind that property assignments may be not specified in the initialization statement and the default object state may be invalid.

I've finally found the information on validation in Mads Torgersen's comment under his post on C# 9. They are looking into options to introduce this in C# 10.
[Edit] If was finally, at least partially, resolved in C# 11 by introduction of required keyword, which can be used on properties. This is quite elegant solution, because it forces assignment on source code level (IDE hilights missing assignments). Still, ability to run some code after all assignments have been made would be useful.

Casting to arbitrary non-generic return type at runtime, C#

I'm trying to make a user-friendly debug framework where users can create more debug variables as easily as possible.
I need to cast an object to the return type of my property/method (bool, int, whatever), without knowing what that return type is.
tldr: How can I return a non-generic type (in this example bool) from
public bool MyGetSetProperty {
get {
object obj = new object();
return (bool)obj;
}
}
WITHOUT specifying "return (bool)"? So something like
return (GenericThingHereThatPassesAsBool)obj;
or
return obj as MyGetSetPropertyReturnType;
----------
Detail:
I want users to be able to create new properties in this class as easily as possible - basically copying+pasting the whole code block below, and only replacing "SerializeAll" with their variable name, and the type declaration "bool" with the type they want on the field/property declarations.
In my getter, I have a couple separate checks to see if the entire debug system is enabled. If not, it returns a default value for the given variable.
[Tooltip ("Serialize ALL XML output fields?"), SerializeField]
private bool debugSerializeAll = false;
/// <summary>
/// Serialize ALL XML output fields?
/// </summary>
[DebugValue, DebugDefault (true)]
public bool SerializeAll {
get {
if (!classEnabled || !debug.debugEnabled)
return (bool)GetDefaultValue (MethodBase.GetCurrentMethod ());
return debugSerializeAll;
}
set { debugSerializeAll = value; }
}
The thing is, I can't return "default" because the default value can be overridden - see the "DebugDefault" attribute where the "default" value for this bool is actually "true", at least as far as my debug system is concerned. The method "GetDefaultValue" accommodates for that, and it returns an object that could be a string, int, bool, anything.
I'm already doing funky reflection stuff to access the MethodInfo, PropertyInfo, etc of the getter and property SerializeAll. I just can't figure out how to not have to also specify the (bool) cast on the return. Again, the goal is as little human editing as possible.
Thank you!

You should be able to do this with a cast to dynamic.
return (dynamic)GetDefaultValue (MethodBase.GetCurrentMethod ());
Bear in mind that the compiler isn't actually making this into a cast to bool. Rather, this makes the compiler ignore compile-time type-safety, and instead the program will use reflection at runtime to figure out the best way to take the value returned from GetDefaultValue and turn it into what it needs to be.
I want users to be able to create new properties in this class as easily as possible...
This is a good principle.
... basically copying+pasting the whole code block below, and only replacing "SerializeAll" with their variable name, and the type declaration "bool" with the type they want on the field/property declarations.
That totally breaks the principle you just mentioned, and results in a bunch of boilerplate code and other code smells.
In theory, you could probably create a Fody Weaver or something to add this boilerplate code upon compilation. But that's probably more work than it's worth.
I would hazard a guess that this is an "XY Problem", where you're asking how to achieve the solution that you've imagined, rather than asking how to solve the problem you're actually facing.
Why should every property in your class return a completely different value if certain private fields are set a certain way? This sounds like a big Separation of Concerns problem, where you're tasking your class with doing two completely different things. I strongly suggest you find another way to solve the problem you're trying to solve. For example, when code tries to get an instance of your class, it could go through a method that checks the classEnabled and debug.debugEnabled concepts (which probably belong in a different class), and returns an instance with the properties all set to their defaults.

Please Link click here -> How to cast Object to boolean?
or
I think you need to study for Generic class
Check if a class is derived from a generic class

How to design a DataType in C# that cannot become invalid

this is a question that can discussed only, but not really answered.
My question is: I have a complex rendering application and with a lot of primitive data types like:
Color
FontSize
FontFamily
Thickness
...
All of them represent a single value, e.g. Color = Value(uint32), FontFamily = Name(string)
I want to design the datatypes in a way, that they cannot become invalid and that you cannot pass invalid values to a method. They should be immutable.
So my first idea, was to define them as structs, but how to handle the initializers (in a struct you cannot override the default constructor and you cannot have initializers for your fields.
For example: The FontSize must be between 4 and 100.
One solution could be the following design:
struct FontSize
{
readonly in size;
public int Size
{
get { return size >= 4 && size <= 100 ? size : DefaultSize; }
}
public FontSize(int size)
{
Guard.IsBetween(size, 4, 100, nameof(size)); // Throws ArgumentException
this.size = size;
}
}
which means, that
FontSize a;
FontSize b = new FontSize(14);
bool equal = a == b; // True
Which is a little bit strange.
How would you design data types like this?
EDIT: Sorry, I have missed the point, that I would do validation in the constructor. But the problem with structs is that there is still the default constructor. With classes I can have null References.
So the point is, that you can only have
Classes with validation in the constructors => You have to check for Null-Refs and you don't get valid default values for variables and properties
OR
Structs with an ugly property to solve the problem with the default constructor. => No Null Refs, but it looks strange to me.

What you're trying to do is a good thing. If your domain classes are created so that they can't contain invalid data then all of your checking is in one place instead of checking for invalid values wherever the classes are used.
The answer is
Use read-only properties
Pass the values used to populate those values in the constructor
Validate in the constructor
Or if you don't want the validation to exist within the class itself (there could be reasons for that, like much more complicated validations), you could
Still use read-only properties
Make the constructor private
Use a static "create" method. It calls the constructor, creates a new object, validates it (perhaps using some extension method) and then returns either the valid object or throws an exception.
Sorry, one more suggestion - I actually like this one best:
Still use read-only properties
Make the constructor internal
Create a separate builder class in the same assembly as your type. That class is public, but the constructor of your type is internal. That way classes outside the assembly can only access the builder class, pass it the parameters, and then it validates the parameters and either creates a class instance or throws an exception.
Pros
Validation still isn't in your data class
You can have multiple builder classes with different validation parameters. So if you need a different version of your data class that has different validation requirements you don't have to modify that class - you just create a different builder class or add a method to the existing one. But you always have control over how consumers create your class.
Con
Because the constructor is internal other classes in the same assembly can create invalid instances.

To ensure that your data type is never invalid, there is no way to do this other that making it a class type. If you use a struct, you'll never be able to prevent someone from using the default parameterless constructor, which will initialize all fields to their types' default values. A custom constructor doesn't have this problem, because you can set up validation inside the constructor.
FontSize a;
FontSize b = new FontSize(14);
bool equal = a == b; // True
Which is a little bit strange.
Indeed, this looks very odd and may cause a lot of trouble for people using your types. If you insist on using structs, then you may consider adding XML comments (if you're using Visual Studio) to the property stating that a default value will be used if the current value is out of range. This might mitigate the confusion, but surely there will be times when someone doesn't read comments popping up in intellisense.

Cast Boxed Object back to Original Type

I expect there's one of two answers to this, either impossible or extremely simple and I've overlooked the obvious Google query.
The underlying issue is that I have a generic object being passed in via an EventHandler that boxes the object and obfuscates the true type; only at runtime do I know what the object is.
Admittedly the dynamic keyword can get around the issue, but I'd like to not lose IntelliSense and everything if I can avoid it. Plus, it doesn't solve not knowing what each of the properties of the generic object are without massive amounts of reflection.
EDIT: The idea is to be able to determine the true type of the an object in a method parameter, and then cast that object as it's true type without knowing it in advance. This is but a simplified example. Boxed may have been the wrong term.
An example:
public class Program
{
static void Main(string[] args)
{
var container = new Container<Containee>(
new Containee
{
Property1 = Guid.NewGuid(),
Property2 = "I'm a property!",
Property3 = DateTime.Now
}
);
var boxed = (object)container;
var originalType = boxed.GetType();
// DOES NOT COMPILE: would like an operation like this
// EDIT: Request for more detail
var actualType = boxed as originalType;
actualType.Entity.Property2 = "But I like this better.";
}
}
public class Containee
{
public Guid Property1 { get; set; }
public string Property2 { get; set; }
public DateTime Property3 { get; set; }
}
public class Container<T>
{
public Container(T entity)
{
Entity = entity;
}
public T Entity { get; internal set; }
}
Clearly that won't compile, as there's not really a way to cast as a variable. However, I'm hoping there's a way to get a reference to the actual object and type, or at least, a way to dynamically re-create the type.
I expect there's something simple I'm overlooking, or a better way to get around it in general. The point is to be able to wrap any object in the container, and figure out later what it was.

The idea is to be able to determine the true type of the an object in a method parameter
That's easy enough (and you're already doing it).
Type actualType = param.GetType();
That will get you the actual concrete type of the object
and then cast that object as it's true type
This is where things come off the rails a bit. The casting operator in C# (usage of which is what people refer to as "casting") can do two things:
Use type-specific explicit conversions to create a new object by applying the conversion to the existing object (note that this is a new reference that is created; the original object's type is never changed)
Allow the developer to reference an object as a type that is at a different level in its inheritance hierarchy than is currently provided (or an interface that is implemented on a type that is lower in the hierarchy than is currently referenced)
In your case, the first option is right out; the casting operator, like all operators, is not polymorphic. That is, an operator is only applied if it is defined on the type that is being referenced, not the object that's being referenced. If you'd like further clarification on this, let me know, but I don't think it's germane to your question so I'm not going to go into it further unless asked.
The second option is the only option that could realistically apply to you, but consider the only two reasons you would want to do this:
So that you can refer to the object as a specific concrete type that is at a lower level than is currently provided (in your case, your object is an object, so that's pretty much as high as it goes)
So that you can refer to an object as a type that is higher in the hierarchy so that you can bypass hidden (but not overridden) members.
(The vast majority of casts are for reason #1)
The reason you would want to use either of those options is so that you can have a strongly-typed object and use the various members defined on that type. But all of these things only apply to types that you know when you're writing the code. It doesn't make sense to cast to a type that is unknown at compile time, as casting doesn't do anything to the actual object (it is, and shall remain, its true type; the only thing that changes is the type of the variable by which you reference the object).
If you can provide a further fleshed-out example of what you're actually trying to do (complete with code as you'd either like or expect it to work), I might be able to provide something modeled a little closer to what you want, but as it's described this is as specific as I can get.

First of all: That's not "boxing". Boxing is for value types, like structs.
Second of all: What you probably need is either:
Compile-time reflection, which C# doesn't have
Dynamic code generation, which you can do (painfully) with Reflection.Emit.
Third of all: Your sample code does variable1 as variable2, which doesn't really make sense. :\ What are you intending to do after that? Perhaps there's a better way.

You could use dynamic:
dynamic actualType = boxed;
actualType.Entity.Property2 = "But I like this better.";
This should compile and work.

var actualType = boxed as originalType;
Just so we're on the same page, let me explain why this is impossible.
var is a compile time construct. It is, identical to declaring the variable with the proper type straight off. Besides being easier to type, it's main use is for anonymous types which, as implied, have no names.
Anyway, to get to the meat of your question, your best bet is to use Dynamic code generation, either with Reflection.Emit or CodeDom (the latter is much easier to understand if you don't know ILASM, but is much slower).
Depending on what you actually want to do, you might be able to get away with something like
if(someObject is Container<Containee>) {
var container = (Container<Containee>)someObject;
//...
}
But, if you can expect literally any type, well... good luck.

The underlying issue is that I have a
generic object being passed in via an
EventHandler that boxes the object and
obfuscates the true type; only at
runtime do I know what the object is.
How do you want to handle it, if the type is only known at runtime? You can't call any specific class methods because you won't know the exact type anyway, unless all objects share some set of methods which can be extracted as interface.
Basically, you have several options:
Use is and do different things for different types:
object value = GetValue ();
if (value is Program)
((Program)value).Run ();
else if (value is Animal)
((Animal)value).Run ();
If all possible types are supposed to share a set of operations, use an interface:
object value = GetValue ();
IRunnable runnable = (IRunnable)value;
runnable.Run ();
Rephrase your question and extend your sample with how you see it working after you've done the ‘magical casting’. This would give us the idea what you're trying to accomplish.

is it bad to use initializer block

Hi I use initializer block in C#
new Something { foo = 1, bar = 2 };
but people say this is bad practice.
I don't think it is wrong, is it?

You need to ask yourself whether your type should be mutable or not. Personally, I like immutable types - they make it easier to reason about what's going on, easier to validate (once the constructor has been called and the state validated, you know it's not going to become invalid) and they're great for concurrency.
On the other hand, object initializers are certainly useful in cases where it is reasonable to have mutable types. As an example, ProcessStartInfo is effectively used as a builder type for Process. It's useful to be able to write:
var info = new ProcessStartInfo {
FileName = "notepad.exe",
Arguments = "foo.txt",
ErrorDialog = true
};
Process process = Process.Start(info);
Indeed, you can even do all this inline instead of having an extra variable. My Protocol Buffers port uses the same sort of pattern:
Foo foo = new Foo.Builder {
FirstProperty = "first",
SecondProperty = "second"
}.Build();
Now one alternative to the builder pattern is constructor parameters (possibly via factory methods). The historical downside of this is that you needed different overloads depending on which properties were being set, and if several parameters had the same type it could be hard to tell which was which. C# 4 makes this significantly easier using optional parameters and named arguments. For example, if you're building an email class you could have:
Email email = new Email(
from: "skeet#pobox.com",
to: "jon#example.com",
subject: "Test email",
body: textVariable
);
This has many of the same benefits of object initializers in terms of clarity, but without the mutability penalty. The constructor call above may have missed out some optional parameters such as attachments and a BCC list. I think this will prove to be one of the biggest benefits of C# 4 for those of us who like immutability but also like the clarity of object initializers.

It's questionable (I won't say "bad") practice to use initialization blocks as a substitute for the appropriate constructor overload, if one exists.
public class Entity
{
public Entity()
{
}
public Entity(int id, string name)
{
this.ID = id;
this.Name = name;
}
public int ID { get; set; }
public string Name { get; set; }
}
If you have this very simple class, then it is generally preferable to write:
var entity = new Entity(1, "Fred");
...than it is to write:
var entity = new Entity { ID = 1, Name = "Fred" };
There are at least two good reasons for this:
You don't know exactly what the constructor is doing. It's possible that, in some circumstances, it might be significantly more expensive to construct the object and then set public properties vs. passing the values through the constructor itself. (You may know that this is not the case, but as the consumer of a class, you shouldn't presume to know care about the implementation details, because they are subject to change).
Your code won't break if one or more of those properties have their names changed, or become read-only (which the ID probably should have been in the first place, but perhaps wasn't due to architectural constraints like that of an ORM).
However, there is one case where you have to use initializers instead of overloaded constructors, and that is when chaining selects in a Linq to SQL/EF query:
var bars =
from f in ctx.Foo
select new Bar { X = f.X, Y = f.Y };
var bazzes =
from b in bars
select new Baz { ... };
This can actually fail with a "no supported mapping" if you use constructor overloads instead of default constructors + initializers. This is, however, a constraint of the technology being used (and an undesirable one at that), and not a coding style issue.
In other cases, you should prefer the constructor overload over the initializer.
If there is no useful/relevant constructor overload that can do the same thing as your initializer, then go ahead and write the initializer, there's nothing wrong with it. The feature exists for a good reason - it makes the code easier to write and read.

but people say is bad practice.
Who says this? At the very least, that’s a controversial statement.
It seems to be all the rage at the moment, and many prominent C# blogs use it extensively.
The advantage over using a constructor is that it’s more readable since the code clearly shows which properties get assigned what values. Compare:
var x = new Something { Foo = 1, Bar = 2 };
with
var x = new Something(1, 2);
Furthermore, if no appropriate constructor is present, the code is more concise than manually assigning to properties:
var x = new Something();
x.Foo = 1;
x.Bar = 2;
Personally, I prefer immutable objects (i.e. objects that, once created, cannot be changed). Unfortunately, the initializer blocks cannot be used in conjunction with such objects (at the moment) because to make this pattern work the object has to have property setters, which an immutable object doesn’t have.
But as long as the object used isn’t immutable I don’t see a compelling reason against using the initializer notation.

Initializer blocks are GREAT practice for the following reasons:
You get to create an object and override its properties before getting its reference
this.ObjA = new ObjA
{
Age = 20,
Name = "123",
};
// this.ObjA will not be set until properties have all been defined
// - safer when multithreading
The parameter-less constructor can still do things behind the scene
(e.g. initialize state members).
You can use in conjunction with constructors with parameters
this.ObjA = new ObjA(20)
{
Name = "123",
};
Using parameter-less constructors is better for (de)serializing scenarios
You can create various objects, change their state via GUI, serialize them, deserialize them elsewhere.
This practice forces authors to write more robust code - where the order in which things are done is less lightly to cause the application to crash every time the class's metadata is changed.

There is nothing wrong with initializer blocks, but if your type for example has many properties, and only a couple of them need to be set on every instance, then you should make them required in a constructor.
The user of your class will know that they can't create an object without specifying those values.

The properties that are essential for the object work, should be initialized in the constructor, so you should provide the appropiate parameters in hthe contstructor.
Initializer blocks are very handy for several of the new features of C# 3.0, but you should keep in mind, that they are not here for replace the parameters in the constructor.

I think it's good.
Because it reduces your typing a lot