Develop Reference

Is it possible to get the Collection using reflection if i have the member of collection?

I have a sample Entity Student as below.
public class Student
{
private string _name;
public string Name
{
get
{
return _name;
}
set
{
_name = value;
}
}
private int _credits;
public int Credits
{
get
{
return _credits;
}
set
{
_credits = value;
}
}
}
I have another Class which is descendent of System.Collections.ObjectModel.Collection as below.
public class StudentCollection : System.Collections.ObjectModel.Collection<Student>
{
//SomeCollection level validations.
}
Now I am creating the student Collection Like StudentCollection c1 = new StudentCollection();.
The question is If I have a student object which is the member of c1 collection then is it possible to get the complete collection to which the object belongs to Using Reflection?
If its not possible using reflection then is there some other way out through which the above is possible.

I think you mean, given an instance (e.g. Student student), Can I get the collection that the instance belongs to.
If so, the answer is no, not using just the student.
If you have multiple collections (e.g. List<StudentCollection> studentCollections) then you could search through them all to find the list that contains the instance.
var collection = studentCollections.Where(collection => collection.Contains(student)).SingleOrDefault();
collection will then be either the collection that contains the student or null if there was no match.
The performance could be pretty awful if the collections get large though. In that case you would want to look into some sort of indexing, possibly using Dictionary.

Yes, but it is probably not what you want.
If you have the "item" you could iterate through all objects in scope, and if the object is a collection, check if the collection contains the item using Collection.Contains(item). Note that there could be multiple collections holding the same item.
This will be a very costly operation and pretty complex to implement, so most likely not appropriate for your purpose, unless you are making some kind of debugging tool or similar.
If you have a limited number of "candidate" collections, you can check if any of them contains the item by calling Collection.Contains(item).

What is the difference between an Indexer and a List in c#? [duplicate]

I'd like to use indexers more, but I'm not sure when to use them. All I've found online are examples that use classes like MyClass and IndexerClass.
What about in a school system where there are Students and Teachers, and each Teacher has a list of Students that they're in charge of - any need for indexers in that scenario? For simplicity's sake: each Student can only belong to one Teacher.

Indexer is a highly specialized property which allows instances of a class (or struct) to be indexed just like an array (properties can be static but indexers cannot).
Why to use indexers:
instead of a new data structure, the class itself is a data structure.
simplified syntax - syntactic sugar
When to use:
if your class needs list(/array) of its instances (example 1)
if your class represents list(/array) of values directly related to your class (example 2)
Example 1:
public class Person{
public string Name{get; set;}
private Person[] _backingStore;
public Person this[int index]
{
get{
return _backingStore[index];
}
set{
_backingStore[index] = value;
}
}
}
Person p = new Person();
p[0] = new Person(){Name = "Hassan"};
p[1] = new Person(){Name = "John Skeet"};
Example 2:
class TempratureRecord{
private float[] temps = new float[10] { 56.2F, 56.7F, 56.5F, 56.9F, 58.8F, 61.3F, 56.5F, 56.9F, 58.8F, 61.3F};
public int Length{
get { return temps.Length; }
}
public float this[int index]
{
get{
return temps[index];
}
set{
temps[index] = value;
}
}
}

Heres a video i have created http://www.youtube.com/watch?v=HdtEQqu0yOY and below is a detailed explanation about the same.
Indexers helps to access contained collection with in a class using a simplified interface. It’s a syntactic sugar.
For instance lets say you have a customer class with addresses collection inside it. Now let’s say we would like to like fetch the addresses collection by “Pincode” and “PhoneNumber”. So the logical step would be that you would go and create two overloaded functions one which fetches by using “PhoneNumber” and the other by “PinCode”. You can see in the below code we have two functions defined.
Customer Customers = new Customer();
Customers.getAddress(1001);
Customers.getAddress("9090");
If you use indexer you can simplify the above code with something as shown in the below code.
Customer Customers = new Customer();
Address o = Customers[10001];
o = Customers["4320948"];
Cheers.

You typically use an indexer if the class represents a list, collection or array of objects. In your case, you could provide an indexer to provide index-based access to a teacher's students.

An indexer use in your situation would be a TeachersClass class, which would encapsulate the students (collection) and the current teacher. Although you could do the same thing by exposing the list of students, but it does show you an example.
Here is a code example:
public class TeachersClass
{
private List<Student> _students;
public TeachersClass(Teacher currentTeacher, List<Student> students)
{
CurrentTeacher = currentTeacher;
_students = students;
}
public Teacher CurrentTeacher { get; set; }
public Student this[int studentID]
{
get
{
return (from s in _students
where s.Id = studentID
select s).First();
}
}
}

Random order access
You would use an enumerator if your data is normally accessed sequentially.
An indexer on the other hand is useful for directly accessing a specific element, no specific order.
This of course assumes you know the index of the element you want. Comboboxes for example have always supported two values: the string shown to the user, and the id that belongs with it. You could use the id from a selected item in a combobox to directly access the index of your collection, instead of having to search the collection.
The nice thing about indexers in C# is that you can overload them, so you can access items through different kind of keys.

The simple answer (as stated above) is when the class represents/contains a collection of items, the indexer will return the elements of the collection.
public Student this[int index] { ..
In a more advanced case you can create a default behavior with a class and make it look a bit like a delegate, especially when the class represents a mapping, or a process. For example a class that calculates the cooling rate of a beer in the refrigerator:
Instead of typing
temperature = coorsLight.CalculateFutureTemperature(time);
you can condence this to
temperature = coorsLight[time];
if the expected behavior (and intent) of the class is to return a value.

An indexer is a means to select an element from an aggregate such as an array or collection. While I agree in part with Ian Davis, I think indexers represent something more than public API polish.
Indexers are the primary means of accessing arrays and most of the major classes representing collections in the .NET BCL implemented indexers, presumably to provide a common expernce when dealing with types that aggregate other types.
Because indexers are a standard part of the interface to many of the BCLs collection types, and because these types are heavily used, as developers learn .NET as a platform, it is reasonable to suggest that an expectation is created that collections can be accessed using some type of indexer.
If your type's interface matches the expectations that developers have already, then that type becomes easier to use because the developer doesn't have to think. This is true whether the developers in question are internal to your organization or out there in the wild.
Of course there are situations where having an indexer just doesn't make sense, and if thats the case then don't implement an indexer.

Indexers allow instances of a class or struct to be indexed just like arrays. Indexers resemble properties except that their accessors take parameters.
Indexers enable objects to be indexed in a similar manner to arrays.
// C#: INDEXER
using System;
using System.Collections;
class MyClass
{
private string []data = new string[5];
public string this [int index]
{
get
{
return data[index];
}
set
{
data[index] = value;
}
}
}
class MyClient
{
public static void Main()
{
MyClass mc = new MyClass();
mc[0] = "Rajesh";
mc[1] = "A3-126";
mc[2] = "Snehadara";
mc[3] = "Irla";
mc[4] = "Mumbai";
Console.WriteLine("{0},{1},{2},{3},{4}",mc[0],mc[1],mc[2],mc[3],mc[4]);
}
}
Code project

I remember there was this time when I had a long inside a class, and some digits of that particular long meant something (for example if the third digit was a 3 it meant that the chart had a specific type of encoding, horrible system I know but I didn't invent it)
So I did something like this to return the xth digit of the number:
protected int this[int index]
{
get
{
int tempN = Number;
if (index > 0)
{
tempN /= index * 10;
}
return tempN % 10;
}
}
It was protected because a different method used it, so it was kind of a helper. Of course a simple GetDigit(int a) would've been the same thing (and more self-explanatory) but at the time I thought it was one of the few times I thought using an indexer would make sense. Haven't used them since =(.

IMHO, Indexers are probably best if you're trying to spruce up a packaged API - it's not worth the effort for your run of the mill business object.
And if you're making some specialized collection, I'd categorize that as sprucing up your packaged API - even if you keep it all in one module.

Object Oriented - Class Variables

I am pretty new to OOP and looking into things in a bit more depth, but I have a bit of confusion between these 3 methods in C# and which one is best and what the differences are between 2 of them.
Example 1
So lets start with this one, which (so I understand) is the wrong way to do it:
public class MyClass
{
public string myAttribute;
}
and in this way I can set the attribute directly using:
myObject.myAttribute = "something";
Example 2
The next way I have seen and that seems to be recomended is this:
public class MyClass
{
public string myAttribute { get; set;}
}
With getters and setters, this where I dont understand the difference between the first 2 as the variable can still be set directly on the object?
Example 3
The third way, and the way that I understand the theory behind, is creating a set function
public class MyClass
{
string myAttribute;
public void setAttribute(string newSetting)
{
myAttribute = newSetting;
//obviously you can apply some logic in here to remove unwanted characters or validate etc.
}
}
So, what are the differences between the three? I assume example 1 is a big no-no so which is best out of 2 and 3, and why use one over the other?
Thanks

The second
public class MyClass
{
public string MyAttribute { get; set;}
}
is basically shorthand for:
public class MyClass
{
private string myPrivateAttribute;
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
}
That is an auto-implemented property, which is exactly the same as any regular property, you just do not have to implement it, when the compiler can do that for you.
So, what is a property? It's nothing more than a couple of methods, coupled with a name. I could do:
public class MyClass
{
private string myPrivateAttribute;
public string GetMyAttribute()
{
return myPrivateAttribute;
}
public void SetMyAttribute(string value)
{
myPrivateAttribute = value;
}
}
but then instead of writing
myClass.MyAttribute = "something";
string variable = myClass.MyAttribute;
I would have to use the more verbose, but not necessarily clearer form:
myClass.SetMyAttribute("something");
string variable = myClass.GetMyAttribute();
Note that nothing constraints the contents of the get and set methods (accessors in C# terminology), they are methods, just like any other. You can add as much or as little logic as you need inside them. I.e. it is useful to make a prototype with auto-implemented properties, and later to add any necessary logic (e.g. log property access, or add lazy initalization) with an explicit implementation.

What your asking here has to do with encapsulation in OOP languages.
The difference between them is in the way you can access the propriety of an object after you created an object from your class.
In the fist example you can access it directly new MyClass().MyAttribute whether you get or set it's value.
In the second example you declare 2 basic functions for accessing it:
public string MyAttribute
{
get {return myPrivateAttribute;}
set {myPrivateAttribute = value;}
}
In the third example you declare your own method for setting the value. This is useful if you want to customize the setter. For example you don't want to set the value passed, but the value multiplied by 2 or something else...
I recommend some reading. You can find something here and here.

Property is a syntactic sugar over private attribute with get and set methods and it's realy helpful and fast to type;
You may treat automatic property with { get; set;} as a public attribute. It has no additional logic but you may add it later without uset ever notice it.
Just exchange
public string MyLine { get; set;}
to
string myLine;
public string MyLine
{
get { return myLine; }
set { myLine = value + Environment.NewLine; }
}
for example if you need so.
You can also easily create read only property as { get; private set }.
So use Properties instead of public attributes every time just because its easier and faster to write and it's provides better encapsulation because user should not be used get and set methods if you decide to use it in new version of yours programm.

One of the main principles of OOP is encapsulation, and this is essentially the difference between the first example and the other 2.
The first example you have a private field which is exposed directly from the object - this is bad because you are allowing mutation of internal data from outside the object and therefore have no control over it.
The other 2 examples are syntactically equivalent, the second being recommended simply because it's less code to write. However, more importantly they both restrict access & control mutation of the internal data so give you complete control over how the data should be managed - this is ecapsulation.

What is the best way to return two lists in C#?

I am almost embarrassed to ask this question, but as a long time C programmer I feel that perhaps I am not aware of the best way to do this in C#.
I have a member function that I need to return two lists of a custom type (List<MyType>) and I know beforehand that I will always have a return value of only two of these lists.
The obvious options are :
public List<List<MyType>> ReturnTwoLists();
or
public void ReturnTwoLists(ref List<MyType> listOne, ref List<myType> listTwo);
Both seem to be non-optimal.
Any suggestions on how to improve this?
The first way doesn't make it clear in the syntax that only 2 lists are being returned, and the second uses references rather then a return value, which seem so non-c#.

First of all, that should probably be out, not ref.
Second, you can declare and return a type containing the two lists.
Third, you can declare a generic Tuple and return an instance of that:
class Tuple<T,U> {
public Tuple(T first, U second) {
First = first;
Second = second;
}
public T First { get; private set; }
public U Second { get; private set; }
}
static class Tuple {
// The following method is declared to take advantage of
// compiler type inference features and let us not specify
// the type parameters manually.
public static Tuple<T,U> Create<T,U>(T first, U second) {
return new Tuple<T,U>(first, second);
}
}
return Tuple.Create(firstList, secondList);
You can extend this idea for different number of items.

Return this:
public class MyTwoLists {
public List<MyType> ListOne {get;set;}
public List<MyType> ListTwo {get;set;}
}

Your first suggestion isn't two lists. It's a list of lists.
The second option would do what you intend, but you might want to change it to use the out keyword instead of ref so the callers of your method will know the intention of what you're doing.
public void ReturnTwoLists(out List<MyType> listOne, out List<myType> listTwo);

You have a few options:
use a Pair if the lists are meaningless in order:
public Pair<List<MyType>,List<MyType> ReturnTwoLists()
{
return new Pair(new List<MyType(), new List<MyType());
}
You can use out or ref parameters, as you mentioned. This is a good option if one list is more meaningful than the other.
You could use a dictionary if the client will know the keys, or wants to do the work to look them up:
public Dictionary<string,List<MyType> ReturnTwoLists()
{
Dictionary<string,List<MyTpe>> d = new Dictionary<string,List<MyType>>();
d.Add("FirstList",new List<MyType>());
d.Add("SecondList",new List<MyType>());
return new Dictionary()(new List<MyType(), new List<MyType());
}
Or, the most "correct" solution in my eyes, for completeness and consistency, would be to create a simple data container class to hold the two lists. This provides a consumer with strongly-typed, good statically compiled (read: intellisense-enabled) return values to work with. The class can be nested right next to the method.

Create a simple Structure that holds both and return that as the output of the function?

Best hybrid approach to a multi-dimensional array with strong typed indexing

I have what amounts to a multi-dimensional array.
int[][][] MyValues;
What I want is to access the indexes via a strongly typed equivelent, such as an enumeration. I'm aware that you can get the enumeration values from the Enum type, but it's a bit long winded for my tastes.
I'd rather have a way to Strongly type the indexes.
For example:
int CarNumber = MyValues[Racetrack.Daytona][Race.Daytona500][Driver.JGordon];
This would, by virtue of it being enum-like, prevent any out of bounds exceptions from being thrown, plus it gives all the indexes a nice human readable meaning.
I've implemented this using a dictionary approach, but it seems kind of heavy handed:
Dictionary<Racetrack,Dictionary<Race,<Dictionary<Driver,int>>> =
new Dictionary<Racetrack,Dictionary<Race,<Dictionary<Driver,int>>>();
which I can then access via enums, but I don't really like this approach. It seems "ugly".
I'm looking for some alternate methods to represent what is essentially a multi-dimensional array while using human readable indexers, while maintaining type safety (can't accidently use a Driver for a Race, for instance, so simply using consts is not a good approach).
Any suggestions?
This will be a compile time array (example above is not real, just an illustration) so I don't have to worry about inserts or deletes or other manipulations of the array. It will stay immutable, both in values, size and layout.
Using a static class with const values is not a good approach either, since it doesn't enforce that only the set of values defined can be passed as indexers.

It sounds to me that you want to use indexers rather than an array. Assuming the following enums (Formula 1 based!):
public enum Track
{
Spielberg,
Adelaide,
Casablanca,
Liverpool,
Melbourne,
Berlin,
Sakhir,
}
public enum Constructor
{
BMW,
Ferrari,
McLaren,
Toyota,
Williams
}
public enum Driver
{
Hamilton,
Kovalainen,
Raikkonen,
Nakajima,
Glock
}
the basic structure is as follows:
public class Race
{
int Year { get; set; }
Track Track { get; set; }
Driver[] Placings { get; set; }
public int this[Driver driver] { } // placing by driver
}
public class Results
{
YearResults this[int index] { }
DriverResults this[Driver index] { }
TrackResults this[Track index] { }
ConstructorResults this[Constructor index] { }
}
public class YearResults
{
YearDriverResults this[Driver index] { }
}
This of course is a partial implementation but you can do some pretty cool things with indexers this way. Like you can access your information with any combination of values in any order (assuming you set up all the intermediate classes).
Its wordier than a multidimensional array or a tuple-keyed Dictionary but I think will give you far more elegant code.

How about using a triple <Racetrack,Race,Driver> as the key (define your own class) in the Dictionary?
If you really need to use an array, I don't think you can do better than wrapping it in a custom class that allows access only using Racetrack, Race, Driver enums.

Obvious question.. Will List<T> not work for you?

Are the enums reasonably small, with values 0...n? If so, you could use a multi-dimensional array but expose an indexer. Note that the code below uses a rectangular array rather than a jagged array, but you could fairly easily adapt it.
// In a static class somewhere. Just a convenience method to check
// whether a value is defined or not. See comment in indexer.
public static void CheckDefined<T>(this T value, String name)
where T : struct
{
if (!Enum.IsDefined(typeof(T), value))
{
throw new ArgumentOutOfRangeException(name);
}
}
// Somewhere else...
private static int GetLength<T>() where T : struct
{
return Enum.GetValues(typeof(T)).Length;
}
private int[,,] array = new int[GetLength<Racetrack>(),
GetLength<Race>(),
GetLength<Driver>()];
public int this Car[Racetrack racetrack, Race race, Driver driver]
{
get
{
// If you don't care about just getting an
// IndexOutOfRangeException, you could skip these three lines.
racetrack.CheckDefined("racetrack");
race.CheckDefined("race");
driver.CheckDefined("driver");
return array[(int) racetrack, (int) race, (int) driver);
}
}

I don't think the dictionary approach is bad, but it isn't elegant. If you created an alias for your dictionary of dictionary things would look better:
using RaceSetup = Dictionary<Racetrack,Dictionary<Race,<Dictionary<Driver,int>>>;
Or you could create a class that derived from the dictionary:
class RaceSetup : Dictionary<Racetrack,Dictionary<Race,<Dictionary<Driver,int>>>
{}