Should i define a struct for the sole purpose of one function?

Question

I got a function that is in need of a custom data type, one way to approach this problem is by defining a struct however this is only for just one function, wouldn't it be better if i just use a dynamic object instead?

For example:

public struct myDataType(){
    public string name { get; set; }
    public string email { get; set; }
    public string token { get; set; }
}

public bool doSomething(string name, string email, string token){
    myDataType MDT = new myDataType();
    MDT.name = name;
    MDT.email = email;
    MDT.token = token;
    //Do something with MDT
    return 1;
}

Or

public bool doSomething(string name, string email, string token){
    dynamic MDT = new ExpandoObject();
    MDT.name = name;
    MDT.email = email;
    MDT.token = token;
    //Do something with MDT
    return 1;
}

Note:

1. While i can define all possible props in the struct, i don't know how many i need to use.

2. The Example is not real it just shows the 2 possible approaches.

Answer 1

That is not the purpose of dynamic. Dynamic is used when you don't know the type until runtime (and have a good reason to have such a scenario). Usages outside of this just de-value the strongly typed nature of C#, allowing code to compile that could be invalid at runtime.

If you need object A with properties B, C, D, then create that object, even if you are going to use it once. Besides, you will need to use that object when something calls your function and needs to access the properties of the returned object. It's better that those properties are known and strongly typed. You can use a struct instead of a class if you prefer, but make it a strongly typed object.

Edit: The original question was edited to indicate that the function does not return the object. Nonetheless, the above still otherwise holds true - that is, this is not a scenario when you don't know the type until runtime, and therefore it is not the right scenario to use dynamic. Since the usage of the object is short-lived, I would use a struct. See here for in-depth discussion on when struct should be used: When to use struct?

Answer 2

There is no performance impact if you choose any of the two solutions you came up with.

When the compiler meets the dynamic keyword it will do the same, will define a class that contains all the members defined.

for this example:

     new { Property1 = "something", Propert2 = "somethingElse" }

compiler will generate something like:

  class SomeNameChoosenByCompiler 
  {
         public string Property1 {get; set; } 

        public string Property2 {get; set; } 
   }

as you are actually using the object outside of your method i would go with the struct version as it makes the code more readable and easy to understand and maybe scalable in time.

Also, with dynamic you would loose compile-time benefits

Answer 3

You can do it either way.

My personal preference would be to use the strongly typed struct so that if I mistype any of the property names I'll find out when I compile the project. If you use the expandoobject you won't find out until the code runs.

The other thing to consider is that a struct is a value type while an expandoobject is obviously a reference type. This may affect your decision because of the way the two types can be used in the rest of your code. For example, a value type variable cannot be set to null, and they follow different copying semantics.

Answer 4

A variable of a structure type is, in essence, a group of variables stuck together with duct tape. A heap object of a structure type (i.e. a "boxed" struct instance) is processed by the runtime as though it were a class object with a variable of that structure type as its only field; any methods which would operate on the structure as a whole operate on that field, while those which would operate on the fields of the structure operate on its sub-fields.

The ability to binding groups of variables together with duct tape is useful if one will be using the variables as a group; almost all cases where one would want to do that, however, would require that the structure be used in at least two places (e.g. a place it's copied from, and a place it's copied to), though there are cases where all the places might be confined to a single function (e.g. one may have a variables prevState and currentState, each containing a few fields, and may want to be able to take a snapshot of all the variables in currentState and later revert all the variables to their earlier values). Structures can be good for that.

I would suggest that it's often good to have very bare-bones structure definitions. If one has a method which reads through a list and computes the minimum and maximum values according to some passed-in IComparer<T>, having a structure:

struct MinMaxResult<T> { public T Minimum, Maximum; } 

could make things clearer than having a more complicated data type which wraps its fields in properties and tries to enforce invariants such as Maximim >= Minimum, etc. The fact that MinMaxResult is a structure with exposed fields makes it clear that given the declaration MinMaxResult mmr;, code shouldn't expect mmr.Minimum to have any meaning beyond "the last value written to mmr.Minimum, or default(T) if nothing was written." Everything of interest is going to be in whatever writes to mmr; the more concise definition of MinMaxResult<T>, the less it will distract from what's actually going on.