   Heirarchy of Classes/Objects/Properties in C#
  Im currently reading through Learning XNA 3.0 as practically my first book to C#, I was studying C# Primer, although I quit because the book was too outdated at this point, anyways... its been awhile since Ive wrote some C# programs and I keep running across sentences like "object called spriteBatch, which is of the type SpriteBatch."C#'s object oriented nature is really confusing me for some reason xD its all that QuakeC that got to me way back..either way could someone explain the C# definitions of Class, Type, Property and Object. I would love you forever.Sorry for such a newb question, I'm just not getting the definitions I'm running into across google.   
  In general OO:A "type" is a structure or primitive (e.g. an integer, float, class, etc...)A "class" is a complex "type" that contains other "types".An "object" is an instantiation of a "class".e.g. If a class is like a blueprint, then an object is a particular building.[EDIT] wikipedia probably explains it better: http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_concepts   ;  MSDN has some references and tutorials. Hopefully they help:C# Language PrimerAbsolute Beginner's Video Series - I don't know how good this is but it may be worth giving it a try.   ;Quote:Original post by HodgmanIn general OO:A "type" is a structure or primitive (e.g. an integer, float, class, etc...)A "class" is a complex "type" that contains other "types".An "object" is an instantiation of a "class".e.g. If a class is like a blueprint, then an object is a particular building.[EDIT] wikipedia probably explains it better: http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_conceptsThank you =) Now that I saw this I do remember reading about it, Although the book I had was very cryptic on the matter =/ I guess its just one of those things that needs to be drilled into your head.Either way thank you very much you have eased some of my confusion =)also, Mutex thanks for the links, I'll check them out a bit later tomorrow after I'm done messing with sprites in XNA. fun stuff XD I remember doing similar things with BitBlt back in VB6 =P;Quote:Original post by Hartleyeither way could someone explain the C# definitions of Class, Type, Property and Object. I would love you forever.Classes define types. A type is, well, the type of thing that something is. Your type is "human". (Well, you could get more specific or more general than that, but that's the most obvious classification.) C# uses both 'class' and 'struct' to describe similar ideas; we won't worry about the differences for now, and instead just talk about classes. (C++ also uses both 'class' and 'struct', but they're much more similar in C++; the only thing that changes is what's assumed about who can alter what data.)An object, or instance, is... well... an object. A "thing", basically. A value. You are an object of the "human" type. You have a name; that could be seen as part of the information needed to describe you, but it could also be seen as the information that identifies you - i.e. a variable name."The information needed to describe you" takes the form of fields (called data members in C++). Each of these bits of information is itself some kind of "thing", and can be composed of smaller things until we get down to primitives - information that can't be broken down any further. For example, your blood type is actually a surprisingly complex thing (there are many blood factors that aren't commonly talked about), but whether or not you are Rhesus positive is just a boolean value - on or off, yes or no. A boolean is a kind of primitive (along with integers, floating-point numbers - well, approximations, anyway - and individual characters of text).So far, our idea of a class includes "what the objects are" (the type name) and "what the objects have" (the fields). To complete the definition, we typically add some information about "what the objects can do". We do this with methods (called member functions in C++). These are functions that are written inside the class, and "called upon" an instance of the class (using the same '.' notation used to examine field values, except that you also provide a list of parameters for the function call). These functions are special: they can refer to fields named in the class, and when the function is called, it will use the field values of the object that the function was called upon.Of course, you can't make yourself literally part of a computer program, but you could define a class named Human, and a variable 'hartley' of that type. The class 'Human' defines the Human type, and 'hartley' holds objects of that type. The value held by that variable is an instance of the class, whose fields describe you.class Human {  public BloodType blood_type;  public double height, weight, age; // You need to decide what the units are.  // These are of a floating-point type because they are continuous. While  // you might tell someone, for example, that you weigh 160 lbs, you will  // generally actually weigh a fraction of a pound less or more.  // Lots of other stuff potentially goes here. Maybe you can think of some  // possible methods, too.}// somewhere elseHuman hartley = new Person();hartley.age = // whatever your age actually is// etc.Of course, as alluded to above, we could be more specific or more general about what your type is. That's what supertypes and subtypes are for. You are a Human, but you're also a LivingObject, because all Humans are LivingObjects. Similarly, LivingObjects are Objects, so you count as one of those, too (as does everything else whose type is specified using a class or struct). In C# (and most other currently-popular OO languages), supertypes and subtypes are normally sorted out using inheritance.Also, it doesn't really make sense that anyone (well, any piece of code) can just come along whenever it likes, and set your height, weight and age to whatever values it likes, right? What if it set your age to something negative, for example? Your age should only be modified by the normal passage of time, and it should go up at a constant rate. And if a Human is still growing, its height and weight are likely to change in sync with this passage of time. If we leave it up to the outside code to do the calculation every time, someone could easily forget; and even if we somehow made sure it was always done, we'd have a big mess on our hands.That's the main idea behind methods: we can make fields private (meaning that outside code is not allowed to touch them any more), and use methods to update them in controlled, sensible ways (and make sure that things are kept in sync).We also need a way to set the initial value of the members; for this, we use constructors. The Human constructor "gives birth" to a 'new' Human.class Human {  private BloodType blood_type;  private double height, weight, age;   // Of course, I am talking about biological parents here. :)  // I don't intend any political incorrectness.  public Human(Human mother, Human father) {    // Do complicated calculations and roll a bunch of random numbers,    // and decide the baby's height, weight and blood type.    age = 0;  }  public void timeElapsed(double howMuch) {    age += howMuch;    // Do complicated calculations, check what the Human has been eating lately,    // and figure out what happens to height and weight.  }}Human hartley = new Human(hartleys_mom, hartleys_dad);// Perform the simulation to figure out your current state:double then = when_hartley_was_born(), now = current_time();// We can't have truly continuous time in a computer simulation, so we// approximate it with small steps.for (; then < now; then += tiny_amount_of_time) {  hartley.timeElapsed(tiny_amount_of_time);}The property is a concept not (directly) supported by all OO languages. C# does them, however. With a property, you can set up a fake public field that isn't really there. What's really happening is that you provide up to two methods - a getter and a setter - with special syntax. Then the compiler interprets the property name as a field name, and translates attempts to read the field into calls to the getter, and attempts to write to the field into calls to the setter.For example, it makes sense to let outside code check what your weight is, but not to change it. We could make a property called 'Weight', which wraps 'weight' by providing a simple getter:class Human {  private BloodType blood_type;  private double height, weight, age;   public double Weight {    get { return weight; }  }  // etc.}// ...// Use the propertyConsole.WriteLine("Hartley's weight is {0}", hartley.Weight);// Illegal - the field is private// Console.WriteLine("Hartley's weight is {0}", hartley.weight);// Illegal - the property does not provide a setter// hartley.Weight = OVER_9000;It's a common coding convention for C# programmers to put field names in lowercase, and use an uppercase first letter for corresponding property names, if there are any. But don't fall into a trap - properties are not meant to exist for every field (and certainly not meant to allow both getting and setting for every field - after all, you could just make the field public instead), and they aren't required to correspond to a specific field. For example:// Make sure you know about complex numbers before trying to follow this// example: http://en.wikipedia.org/wiki/Complex_numberclass Complex {  private double real, imaginary;  public double Real {    get { return real; }    // 'value' is a C# keyword that is used for implementing setters.    // It represents whatever value was used for setting.    set { real = value; }  }  public double Imaginary {    get { return imaginary; }    set { imaginary = value; }  }  // So far, that looks like we're just making a property for every field.  // But watch:  public double Magnitude {    get { return Math.sqrt(real * real + imaginary * imaginary); }    set { // BTW I haven't actually tested any of this ;) double scaling_factor = value / Magnitude; real *= scaling_factor; imaginary *= scaling_factor;    }  }  public double Angle {    get { return Math.atan2(imaginary, real); }    set { double length = Magnitude; real = Math.cos(value) * length; imaginary = Math.sin(value) * length;    }  }  // which also allows us to implement:  // 'static' methods belong to the class, rather than the object. They're  // basically non-object code that lives within the class definition. We  // put it here because the code *has to do with* Complex objects, even if  // it doesn't *operate on* an existing Complex.  public static Complex rectangular(double real, double imaginary) {    Complex result = new Complex();    result.Real = real;    result.Imaginary = imaginary;    return result;  }  public static Complex polar(double magnitude, double angle) {    Complex result = new Complex();    result.Magnitude = magnitude;    result.Angle = angle;    return result;  }  // The reason I didn't use constructors there is because they would conflict:  // they both take two doubles as arguments, and there'd be no good way for  // the calling code to say which to use. Of course, the compiler would also  // report an error ;)}// Now we can treat a Complex instance as if it were in rectangular OR polar// coordinates under the hood. And we can also change the implementation and// not have to change any of the calling code. I.e. we could make the fields// represent magnitude and angle, and change the properties so that Magnitude// and Angle work directly, and Real and Imaginary do math. And we wouldn't// even have to rewrite the "factory" methods 'rectangular' and 'polar',// because they use the properties and are thus shielded.// So, for example, somewhere else we can now do:Complex c = Complex.polar(3, Math.PI);// that makes the Real component 0 and the Imaginary component 3.c.Real += 3;// That's exactly equivalent to 'c.Real = c.Real + 3'; thus the getter is// called, 3 is added to the result, and the setter is used to assign the// sum back. Since c.Real was 0 before, now it is 0 + 3 = 3.Console.WriteLine("Angle in degrees: {0}", 180.0 * c.Angle / Math.PI);// Should display an angle of 45, give or take a tiny fraction, if I did it right.