Develop Reference

How to fill a random object with random data at runtime

I want to create a little testing tool for my program, which fills all properties of a random object (unknown type at compile time). A sample structure:
public class HeadObject
{
public Company Company { get; set; }
public CompanyAddress CompanyAddress { get; set; }
public List<Details> Details{ get; set; }
public ApplicationUser AppUser { get; set; }
}
and e.g the class Company would look like this:
public class Company
{
public string CompanyName{ get; set; }
public string PhoneNumber{ get; set; }
public Address Adress{ get; set; }
public int CompanyNo{ get; set; }
public List<Employee> Employees{ get; set; }
}
its pretty simplified because in each HeadOjbect there are around 30 properties which may contain sub properties or a property can be a list etc.. I need to populate ~30 HeadObjects at runtime. I already tried it with different libraries like GenFu, nBuilder or Bogus.
The last 2 have the problem that I have to fill the properties by myself only the data is generated. GenFu looks like it can only deal with primitive properties like int, string, ... And if you imagine the HeadObject as a root of a tree, then there would be
~ 300 Nodes per tree
Height of a tree: between 1 and 7(!)
~30 Different trees (HeadObjects)
so it would take days to write this all down by myself and maintenance would be a pain.
I appreciate any kind of idea.
UPDATE
Thanks for your replies! How can I initialize the objects? e.g I get the Company property of my head object and then I want to initialize it to be able to fill it. My method (its recursive) starts like this:
private static T FillAllProperties<T>(T masterObject) where T : new()
{
try
{
Type masterType = masterObject.GetType();
T headObject = new T();
......IF primitive Type fill it and return the value
otherwise get Properties into firstProperties.......
foreach (var propertyInfo in firstProperties)
{
var objectInstance = FillAllProperties(propertyInfo.PropertyType);
headObject.GetType().GetProperty($"{propertyInfo.Name}").SetValue(headObject, objectInstance, null);
}
Now I have 2 questions:
is my way to initialize the generic type correct?
at the recursive call I get the following error :" The type 'System.Type' must have a public parameterless constructor in order to use it as parameter 'T'....
I probably need another "construction" for this algorithm, but how..?

You are going to go through deep pain...
Basically the idea is to iterate through the object's properties and randomly fill them.
You can iterate using YourObject.GetType().GetProperties() then using PropertyInfo.PropertyType to know the type.
Then with each Proprety Type you can check whether it is a simple (i.e. int, double...) structure or a more complex object (by using Type.IsPrimitive, Type.IsClass or Type.IsValueType).
If it a class, you recursively call the same method, because it means you have a complex type.
If it is a structure, then maybe you should iterate over the fields instead of the properies ?
If it is a primitive you can set its value using PropertyInfo.SetValue(), but how are you going to randomize anything ? You need to perform a switch on .Net base types then generate a value at random for each type.
By the way, a string is a class, not a primitive, so you will need to make a special case for this one.
Also, List<string> is a funny one, because it is an Enumerable object. So it is another specific case.
And if you want to have fun, try out a Dictionary, or better, Tuple...
Anyway, there is no simple way to perform this. Your simple testing tool will soon become a nightmare because of all the cases you couldn't even see from far away...
Maybe there is a better option to test your program than filling it with random values that don't have any actual meaning ?

If you do not know the properties at runtime, you will have to use Reflection. But starting with 30 properties, I would probably use it regardless (or look if I made any mistakes in my design). Writing that much manually is just too prone to mistakes.
A alternative might be to have a ISelfRandomizing interface with a SelfRandomize() function, so each type input can carry it's own randomization code. And hope people actually provide it.
Something that might be viable for your case: structs by default use reflection for comparison. What would be the equivalent of a base class for them, has reflection based fallback code. You are invited to override it, but if you do not it just "works". You could make a abstract base class that you use for all those classes. That way you only need to write the reflection code once.
As for the actual randomization: Random. A common mistake is creating new instances of Random in a loop. Do not do that. You want to keep a single Random instance around as long as possible, for optimal randomisation. I have no sensible way to transform a Integer return into a string, so the next best non-sensible thing is to create a large random number and call ToString() on it. That will give you something to put in those spots at least.

Memory allocation of a Class auto properties

I have a class with multiple properties. For example
public class Customer
{
public int id { get; set; }
public string abc{ get; set; }
public bool abcd { get; set; }
public string abcde { get; set; }
public string abcdef { get; set; }
public string abcdefg { get; set; }
public string abcdefgh { get; set; }
public string xyz { get; set; }
}
Now I want to know how much memory space is consumed by the get set properties.
I only require few of the properties in one of my API call and all of these properties for another API call.
So I want to know whether I should create two different classes and use them for my separate API calls or just use one common class with multiple get set properties and use it for my API calls.
Any guidance will be much appreciated. Thanks

the int and bool will typically be packed together into 8 bytes; the string references take 4 (32-bit) or 8 (64-bits) for the references. If the strings have non-null values, then that space will be allocated separately and will be whatever the string needs.
But frankly: unless you're allocating millions of them, splitting it into 2 different types won't save you anything real - it will just be yak shaving. Especially for the scenario where the strings are null.

We have to exclude the string. This one can be anywhere from "null" to "whatever Max Lenght for string was today".
Theoretically a Autoimplement Property should cost as much as a minimal, manual property: One backing field. One get and one set function for the entire type. The single most important rule about properties is to not accidentally access the backing field in class code. And Autoimplement Properties do that, by simply not giving the Backing Field a name you could use. It is still there. It propably has a name derived from the Property name for Reflection. But your code has no realy way to access it.
Theoreitically, because now coems in the JiT. The JiT can do a lot of Optimisations:
Those Automatic accessors are very little code. So there is a decent chance that the cost of Inlining them is below the cost of calling them. So I give it a 90% chance the JiT will inline those.
If you create a temporary variable to use it the next line, this one might run into DeadCode detection. Wich means it will be cut out and replaced by the originall access.
But of coruse it goes the other way too. In order to get around the overhead inherent in ArrayBounds Checks, the JiT might detect "redundant Acesses" with teh same Index and create a temporary variable to use.
While I have not read about it yet, I would not rule out that the JiT can even cut unused properties from classes. It is all just runtime optimisations. It at least can cut unaccessed varriables (and their initialsiation) out as dead code. As I found out when I tried forcing a 2 GiB OOM:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace OOM_32_forced
{
class Program
{
static void Main(string[] args)
{
//each short is 2 byte big, Int32.MaxValue is 2^31.
//So this will require a bit above 2^32 byte, or 2 GiB
short[] Array = new short[Int32.MaxValue];
/*need to actually access that array
Otherwise JIT compiler and optimisations will just skip
the array definition and creation */
foreach (short value in Array)
Console.WriteLine(value);
}
}
}
I agree that this is Micro Optimisations. But even more, those might be ones the JiT can do for you already. So you might save nothing at all. Personally I prefer read- and debugability of code way before such Optimisations. I can often do something "ineffective" because I can rest in the knowledge the JiT will propably deal with it.

Why is it desirable to use all properties instead of public instance variables in c#?

I know properties have some advantages, but if you think you won't need a property, what's the harm in making it a public instance?
People say that changing the public field to a property will break code if you try to do it later on but in my experience changing it to a property breaks nothing.

I think that people mean that it breaks ABI (binary) compatibility, not the API (source) compatibility.
Although the syntax is identical, behind the scenes, access to properties and access to member variables are compiled differently.
That said, if your variable/property is not to be used from an assembly that you yourself do not compile, then there is no harm in changing it. But if it is part of a public interface, then it is better to make it a property, so that you will not regret it in the future.

It's about maintaining both binary and source compatibility. Some time in the future you may decide to make logic of assigning values more complex and to change fields to properties. This is where the problems emerge.
Public fields can be used as out and ref parameters. Properties cannot. This will produce uncompilable code.
Different Reflection methods are used to access fields and properties. That means any code that gets or sets values using Reflection will break, and you'll know about it only in run time.
Different IL operators are used to access fields and properties. That means cross-assembly compatibility is broken when fields are changed to properties and only one assembly is recompiled. This will make your program fail at run time.

I concour with you, if the property is just a wrapper on the field.
And the guys at Coding Horror looks like having our same opinion, I find very funny that frightened icon they use :)
http://www.codinghorror.com/blog/2006/08/properties-vs-public-variables.html

A simple program.
Here I am adding two properties and one variables. We can use properties as per our decision. But I prefer to use properties because it helps to implement some bussiness validation and can hide the business logic form calling party.
class Program
{
static void Main(string[] args)
{
Human h = new Human();
h.FirstName = "Test";
h.LastName = "User";
Console.WriteLine(h.FullName);
Console.Read();
}
}
class Human
{
public string FullName { get { return FirstName + " " + LastName; } }
public string FirstName;//{ get; set; }
public string LastName;//{ get; set; }
}

How to compare two instances' contents in C#?

I have a silly question here.
I define a class with many data members, like this:
public class A
{
public string Name { get; set; }
public double Score { get; set; }
//...many members
public C Direction { get; set; }
public List<B> NameValue1 { get; set; }
public List<string> NameValue2 { get; set; }
//...many members
}
Now, I'm writing unit test code and want to compare two instances of class A.
But I found this doesn't work:
Assert.AreEquals(a1, a2);
I must override Equals method to do that? C# can't help with this by default?
Or I can serialize these two guys and compare the filestream?
Thank you.

The default equality implementation, for reference types, is reference equality: "is this the same instance". For equivalence, yes, you should write that yourself if you need that, but: it is rarely all that useful really (and there's a problem, because if you override Equals you should override GetHashCode too, with a suitably parallel implementation.
Personally, I'd compare manually in your unit test if this code isn't part of your main system.
Lists are a pain too, since there are three options:
same list instance
different lists with same content instances
different lists with equivalent content instances
You probably mean the last, but that is the same problem, repeated.
Re serialization: that is tricky too, since it depends on the serializer and the contents. I wouldn't recommend that route unless a: your type is already being used for serialization, and b: your chosen serializer guarantees the semantic you mean. For example, BinaryFormatter does not (I can provide a concrete example if you want, but trust me: this is not guaranteed).

C# Properties and this-keyword

When should I use the this-keyword for properties in code?
public class MyClass {
public string MyString { get; private set; }
public void MyMethod() {
OtherClass.DoStuff(MyString); // Or this.MyString?
}
}
I know that if the type and name of a property is the same you have to use this. to make it work.
public string Emailer Emailer { get { return _emailer; } }
What are the guidelines for using this. on Properties and even Methods in a class? I know it makes no difference in the compiled code. It's all about... hold your breath... best practices.

Do whatever you and your team find most readable. Some people like to be explicit; I only specify this when I actually have to. It will make no difference to the compiled code.

If a parameter name and an instance member have the same name, you will need to use this.
Like:
public class MyClass
{
private string something;
public void SomeMethod (string something)
{
this.something = something;
}
}
But I'd advice you to choose names in that fashion that you'll never need to use this. Doing otherwise is just asking for trouble - sooner or later you'll forget this somewhere and will have a hard time debugging your code.

Whether or not to use this is mostly an issue of preference and hence there is no right or wrong answer. It can become a bit of a religous war though with devs. I often find it's best to come to an agreement on the team one way or the other and use StyleCop to enforce the decision afterwards.
Personally I prefer brevity and only use this when it's actually necessary. But I'd choose code base consistency over my personal preferences here because it's a fairly minor issue.
There are a few cases where it's explicitly needed. Extension methods on this and in certain cases to disambiguate an identifier come to mind. I find these are fairly rare though.