We Keep Coding

C# Read attributes from Generic class without instance

Problem Description
I'm trying to implement a very specific sort of cache of objects that I may not be able to instantiate directly (private constructors for instance)
What I want to do is read some information about the particular class, preferably through some kind of interface (which sadly doesn't support static methods defined for every subclass)
In other words:
public class Data
{
public static bool Attribute1() => False;
private Data(...) { ... }
}
public class Cache<T> // T is for instance Data
{
void SomeMethod()
{
bool Value = T.Attribute1()
...
}
}
It's fine if I can make T inherit from some base class or some interface, and to get the attribute through some sort of method or directly. It is very important though that I can
Program multiple data classes A and B, where A.Attribute1() is different from B.Attribute1()
Get the attribute from the data class type without instantiating the data type
Current Solution
I do currently have a solution in the shape of a registry built when the static objects are initialised, like this:
class CacheAttributesRegistry
{
static RegisterAttributes(Type T, bool Attribute1, ...) { ... }
}
class Data
{
static Data() { RegisterAttributes(typeof(Data), true, ...); }
}
class Cache<T>
{
void SomeMethod()
{
bool Value = CacheAttributesRegistry.Attribute1(typeof(T));
}
}
It does exactly what I want, but I'd prefer avoiding a static constructor in every data class, also I don't want it to be possible to accidentally call RegisterAttributes at runtime.
Preferably I'd also avoid reflection because I'd like it to be obvious how to set the attributes for a class without the code magically inferring it in the background.
Am I missing some option or have I just reached some language limitations?

I think I need a static class with a constructor?

So, apologies in advance for the surely poor terminology in this question - I'm trying to teach myself C#, and struggling with a few concepts.
In pseudo-code, I have something like this:
static void Main()
{
// This will create lots of "Item"(s), and do stuff with them
}
public class Item
{
// a bunch of properties
public Item()
{
}
}
Next, I need a UtilityFunction1 that'll do some work - it will be called many times during Main() and passed Items to do some calculations with them. This function needs to set up a Dictionary to do its job. Even though it will be called many times, the Dictionary should only be set up once.
I also need a UtilityFunction2. Like UtilityFunction1, this function also needs a Dictionary to do it's job, which should only be set up once. This function will be called many times by UtilityFunction1.
So, on one hand, it seems like UtilityFunction1 and UtilityFunction2 should be public classes, since they need to have a constructor that populates the Dictionary (which involves variables, looping, and calculations).
On the other hand, I only need one of UtilityFunction1 and UtilityFunction2, so it seems like they should be static methods. But if that's the case, how/when do they do the work to set up the Dictionaries they need?
How do you achieve this?

You could also move your logic outside of Main.
What forces you to use static is that Main method (and class it's part of, usually) is static. That forces all other things (fields, methods, events, you name it) to also be static. The easiest way of curing that headache would be to create new class to hold all things you need.
Create new Logic class and put all things in it. The Item class stays the same. you can move it to separate file for clarity.
Logic.cs:
public class Logic() {
private Dictionary<object,object> dict1 = new Dictionary<object,object>
private Dictionary<object,object> dict2 = new Dictionary<object,object>
public Logic() {
// some logical initializations here
}
private void UtilityFunction1 (Item itemToWorkOn) {
// you can access dict1 directly from here
}
private void UtilityFunction2 (Item itemToWorkOn) {
// you can access dict2 directly from here
}
public void Run() {
// run UtilityFunction1() many times
// run UtilityFunction2() many times
}
}
Item.cs:
public class Item() {
// a bunch of properties
public Item() {}
}
And then just run it in your Main.
Program.cs:
static class Program {
static void Main() {
new Logic.Run();
}
}

Maybe you can think of the Singelton Design Pattern for your UtilityFunction*
https://msdn.microsoft.com/en-us/library/ff650316.aspx
You need a class that has only one instance, and you need to provide a global point of access to the instance.

You may use a static constructor. A static constructor is guaranteed to be executed just once for the class and before the class is used for the very first time. A static constructor is a very good place for initialization of static properties. It may look like:
public class ExampleClass
{
public static readonly IDictionary<int, Item> Items;
static ExampleClass()
{
Items = new Dictionary<int, Item>();
}
}
However, be careful with static stuff as it usually decreases the modularity and testability of a program. Therefore the use of a singleton pattern might be a better solution rather than a static constructor.

C#/AS3 How do I create a public global data object that any other object can read, but only certain objects can set?

Here is the conundrum. I have a specific set of state variables that are used in almost every supporting object I have, and I want those variables to be able to be read by any object that needs to read them, but I want to protect them so that only 1 object has the ability to set them.
For example, lets say I am making a poker game. Variables like:
- Minimum Ante
- Maximum Bet
- Maximum Number of Players
- Current GameState (Placing Bets, Shuffling, Dealing, Paying, etc.)
Personally, I prefer small compact component classes, so lets say I have the majority of the poker game logic in 1 controller class, but i have 50 supporting objects that handle everything that isn't the poker game logic itself, such as a PlayerInterface, a graphics controller, 'The Deck' to handle shuffle and deal logic, etc. Alot of my smaller support classes need to see what the minimum ante is, and the current method I am using is for the controller class to pass these variables into the supporting classes as parameters.
The obvious downside to this is I have 50 supporting objects all holding on to their own local variables for minimum ante to hold the same information that I am passing to them from the controller. Wasted parameters, memory, and opens a ton of risk if any of those variables ever get out of sync.
So, how to I make these variables global so everyone can access and read them? The knee jerk reactionary answer is some public static variables, however this presents the problem that anyone could also write to them. Not only do I not want my supporting objects having the power to change the minimum ante without the controller's knowledge, but I also don't want the client shell that holds the poker game to be able to change them without first going through the proper checks contained in the controller.
So what do I do? Someone once mentioned to me the idea of a Singleton, but after plenty of research, most of it a few years old or more, I found about a 50/50 split in the community who say Singletons are a good idea vs those who think they aren't.
If not singletons or statics, then what? I am open to any ideas to research and try out.
Remember, I want any object, anytime, anywhere to be able to GET the data it needs, but only a very specific object to have the ability to SET the data, should it need to change, so that it can filter through the proper checks. By proper checks, I mean for example in the poker game, if a player has the ability to change the Minimum Bet on the table, he should only be able to do so between hands, or before a tournament begins. I don't want him messing with these things during play.
Thanks in advance for any input.

You could use interfaces approach here.
Declare two interfaces as
public interface IReadOnlyAccess
{
int Property{get;}
}
public interface IFullAccess
{
int Property{get;set;}
}
Then your class would implement both interfaces like
public interface MyClass: IReadOnlyAccess, IFullAccess
{
public int Property{get;set;}
}
Then wherever you need full access you get it via IFullAccess, if otherwise - via IReadOnlyAccess.

Make an inner class, it will have access to the main classes private vars:
public class OuterClass
{
public string StringProperty { get; private set; }
public InnerClass CreateInnerClass()
{
InnerClass ic = new InnerClass(this);
return ic;
}
public class InnerClass
{
private OuterClass _outer;
public InnerClass(OuterClass oc)
{
_outer = oc;
}
public string Prop
{
get
{
return _outer.StringProperty ;
}
set
{
_outer.StringProperty = value;
}
}
}
}
So create the main class that most people have readonly access:
var oc = new OuterClass();
oc.StringProperty = "123"; <-- not allowed, is `readonly`
To write to properties, create inner class instance:
var oc = new OuterClass();
var ic = oc.CreateInnerClass();
ic.StringProperty = "123";

Seems like the cleanest, easiest solution is to have everything done in your controller class.
Let's say something like this:
AS3:
//adding the final keyword, locks this class so others can't extent/inherit from it
public final class MyController {
//create a privately scoped var (it can only be accessed in this class)
private var minBet:Number = 0;
//create a public getter that can be read by any class/object
public function get minimumBet():Number {
return minBet;
}
private function set minimumBet(value:Number):void {
//do you checks etc
minBet = value;
}
}
C#
//sealed in C# is the same as final in AS3
public sealed class MyController
{
private float minBet = 0;
public float minimumBet
{
get { return minBet; }
}
}
instanceOfMyController.minBet //will throw an error
instanceOfMyController.minimumBet = 10; //will throw an error
instanceOfMyController.minimumBet //will supply the value of the minBet var
If you're doing a lot cross-language code, consider checking out something like Haxe which can compile out to AS3 or C# with the same code.

Using constructors of monobehaviors

OK, I know why we don't use constructors on monobehaviors in Unity. For nearly all of the use cases, Start and Awake fit perfectly. Usually.
However, there's a great C# feature that only can be used with constructors — readonly fields. In my particular situation, I work on a project with a lot of developers and write an abstract MonoBehavior that will be subclassed and rewritten a lot of times by a lot of different people. And I want a field to act like constant throughout object's lifetime (or it WILL introduce strange, hard-detectable bugs) but with different values in different subclasses — in other words, a classic use-case for a readonly field. (I don't want to use properties because they have no language-enforce obligation of staying the same.)
So — can I safely use MonoBehavior's constructors? Won't some strange dragon come out of the lair somewhere down the road? What should I know if I choose to use them?

I think the main reasons Unity wants you to stay away from using the constructor is that the constructor isn't called on the main thread, and the constructor is called before serialized data is restored to the object.
So if the readonly fields you're setting in the constructor depend on data from serialized fields, then they won't work right. And if they don't then you can just assign them at initialization.
You could also use a container object to keep your readonly values, but there's nothing stopping someone else from re-assigning that container later.
using UnityEngine;
using System.Collections;
public class ReadOnlyTest : MonoBehaviour {
public string part1 = "alpha"; // change these values in the editor and
public string part2 = "beta"; // see the output of the readonly variable "combined"
public readonly string combined;
// just assign to readonly vars.
public readonly string guid = System.Guid.NewGuid().ToString();
public readonly float readOnlyFloat = 2.0f;
public class ReadOnlyContainer {
public readonly int readOnlyInt;
public readonly float readOnlyFloat;
public readonly string readOnlyString;
public ReadOnlyContainer(int _int, float _flt, string _str) {
readOnlyInt = _int;
readOnlyFloat = _flt;
readOnlyString = _str;
}
public override string ToString() {
return string.Format("int:{0} float:{1} string:{2}", readOnlyInt, readOnlyFloat, readOnlyString);
}
}
public ReadOnlyTest() {
combined = part1 + part2;
}
public ReadOnlyContainer container;
void Awake() {
if (container == null) {
container = new ReadOnlyContainer(Random.Range(-100,100), Time.realtimeSinceStartup, System.Guid.NewGuid().ToString());
}
}
void Start () {
Debug.Log(container.ToString());
Debug.Log("combine1: " + combined);
Debug.Log("guid: " + guid);
}
}

Many unity classes are created by reflection, and there's no way for unity to non-default constructors properly; hence the limitation.
#Calvin's answer points out one very good option: create classes that are not derived from MonoBehaviour; these can have constructors like any other C#. You can put those classes into fields in MonoBehaviours as long as your code can tolerate missing instances. If you use the typical quasi-singleton pattern from #Calvin's answer you'll always get an instance when you need one, and you can push the 'give me an instance the first time' logic into a method that can be overridden in derived classes to customize behavior.
If you want constant-like behavior, with the option of different values in derived classes it may be easier to define a method rather than a field. The method is effectively read-only, and it has more predictable mutations as per #Jerdak's answer.
If you must have constructors, the last option is to use the monobehavior as a minimal placeholder and write all of the interesting stuff in a class of your own, then delegate all of the work in the Monobehavior to your class.
using UnityEngine;
using System.Collections;
public class OuterPlaceholder: MonoBehaviour {
public InnerBehavior _Inner;
public void Awake() {
if (_Inner == null) {
_Inner= new InnerBehavior(4);
}
}
public void Update()
{
_Inner.DoUpdate(this);
}
}
public class InnerBehavior
{
public readonly int UpConstant;
public InnerBehavior (int up)
{
UpConstant = up;
}
public void DoUpdate(MonoBehaviour owner)
{
owner.transform.Translate(Vector3.up * UpConstant * Time.deltaTime);
}
}
This option may work best if you are sure you're going to get a lot of complex inheritance as the project evolves.
Finally: It's perfectly OK to name the field _ReadOnlyField or _DoNotWrite or whatever to tell users not to muck with it. All Python programmers live with the possibility of somebody doing far worse things and it seems to work out fine most of the time :)

From the script refs:
If you attempt to define a constructor for a script component, it will
interfere with the normal operation of Unity and can cause major
problems with the project.
MonoBehaviours are constructed many times during serialization, something Unity does quite frequently in the editor and I suspect there is a lot more going on the hood to hook the C layer to C#. Ultimately the behavior is undefined so it's best not to try.
Regarding "but with different values in different subclasses", from MSDN:
assignments to the fields introduced by the declaration [readonly] can only occur as part of the declaration or in a constructor in the same class.
So no modification in derived classes.

Does redirecting to other classes via Properties cause slowdown and/or save space in C#?

So let's say I have a Clone object with these properties. Clone might have different mass or name based on the file it was loaded from, but these values never change at runtime. However, Clone instances to have some autonomy and properties which do change per instance, so they can't all be the same instance.
public class Clone
{
public float Mass { get; protected set; }
public string Name { get; protected set; }
public Clone(string filePath)
{
Name = //read name from file
Mass = //read mass from file
}
}
Now, what I want to know is, what are the benefits and drawbacks (if any) of doing this instead:
public class CloneInfo
{
public float Mass;
}
public static class Database
{
public static Dictionary<string, CloneInfo> Lookup;
[...load whole dictionary from files...]
}
public class Clone
{
public string Name { get; protected set; }
public float Mass { get { return Database.Lookup[Name].Mass; } }
public Clone(string name)
{
Name = name;
}
}
With this 'redirecting' method, I keep the simple syntax of Clone.Mass, but don't have to store a Mass value for each instance. Since I've got thousands of clones wandering about, this is a good thing. I'm mainly interested in 'redirecting' because of the syntax. I realize that I could simply manually do the database lookup every time I wanted a particular clone's mass, but I'd rather keep the usage of the class nice and straightforward. Is there any drawback to this? Is the property going to be slower than direct lookup in the static database? Does the property take up any space in a Clone instance?
Or, perhaps, is this a use case C# already has an answer for which I'm not aware of? Seems like write-once properties which are common among many instances might be somewhere in this beautiful language.

If all the clones of a certain type have the same mass, that sounds like a job for subclassing:
class Clone
{
public abstract float Mass { get; }
}
class HeavyClone : Clone
{
public override float Mass { get { return 12345.6; } }
}
class LightClone : Clone
{
public override float Mass { get { return 1.23456; } }
}
More to the point of your question: if you are more constrained by memory than by processing time, your approach may give some benefit. If memory is plentiful, and cache performance is not an issue, the approach you suggest probably has little value. It certainly seems to complicate the code quite a bit.
The usual advice is: write simple code, measure the performance, and, if the performance is inadequate, address the performance bottlenecks. That way, you only have complicated code in places where it actually helps your application's performance.
Another thought: instead of having have the clone index into the dictionary with the Name string, why not just have a CloneInfo field:
public class CloneInfo
{
public float Mass;
}
public class Clone
{
private CloneInfo _info;
public float Mass { get { return _info.Mass; } }
public Clone(CloneInfo info)
{
_info = info;
}
}

Suppose that we have a lot of accesses to Mass property. If in each access you try to load the Mass value from database, it can be a very heavy duty for your application and here will be a bottleneck. If the Mass value can be cached in the object, you can easily load it for once and keep it for further usages.