When should you use Classes instead of Method. I have an impression that it's much easier to transfer information and stuff like that into a method than to a Class. I wonder if there's anything I should consider when I should decide if I shall use a Method or a Class.

Thanks

They are different things.

A method is a function call on a class. You don't really choose between them.

A class generally represents a concept within you application and methods are the operations on those conepts.

Maybe if you give us a more specific example of what you are trying to do we can help you decide a structure for your code.

Did you mean to say Static vs. Instance? Reference vs. Value?

He is saying that a Class is merely a container (a container that describes objects within your game world).  A method is contained in a class.  A class has Methods which are functions calls

public class Class1
{
    public Class1()
    {
        public void MyMethod()
        {
            //Insert Method Code here
        }
    }
}

Above is a crude example, but Class1 is the class and MyMethod is the name of a function within the class.  When in the context of classes it is called a method. 

Like I said it is a crude example and I am sure there are heaps of people that can explain it better than I could.  But I hope this helps.

Kind Regards
Michael Rogers

An easy way to differentiate the two; a Class is a noun and a Method/Function is a verb. The verb handles the actions of the noun.

Or... The class is the guy and the method is what the guy does (like run, walk, sleep...)

Could you by any chance mean the difference between a Struct and a Class?

What I really meant (I understand that it wasn't very clear) is if it's better to create a new class, or a new method in an existing class. If you want to create a way to keep track of a sprite on the screen (position, speed, size, etc.). Would it be better to create a method in an existing class (example: Game1) to handle this, or create a new class. Because I thinks it's very tiresome with class calls this size:

It always depend of what you want.

It would be a lot of dificult to maintain a game made only with methods. It would not be modular enough.
If the project starts to rise, it would be a lot easier to make some gameplay class (for example: Character, Enemy, Item) and low-level classes (Sprite, TileMap, PhysicsEntity).

As others have said, it really depends on what you are trying to accomplish.  This could be seen as a larger question for object-oriented programming in general and not just for game development:

For any given piece of functionality, is it more suitable to encapsulate this functionality as a new class, or to place the functionality in an existing class?

Here are a few questions that might indicate the need to create a new class:

• Will this functionality be something I want to pass around as a parameter to other classes or methods?
• Will implementing this functionality require maintaing internal state that should persist over several calls, but is not the direct concern of another class?
• Will this functionality be re-used as a component by other classes?

Another way to look at this decision is to consider the Law of Demeter, also called the Principle of Least Knowledge, a guideline for object oriented design:

http://en.wikipedia.org/wiki/Law_of_Demeter

Here is a (non-programming) example from the Wikipedia article:

When one wants to walk a dog, it would be folly to command the dog’s legs to walk directly; instead one commands the dog and lets it take care of its legs itself.

Let's say you have a "leg" class (a sprite) that you need to move around the screen.  You could certainly create a method inside the leg class to tell the leg to move around the screen, but this would violate the principle of Least Knowledge.  Alternatively, you could create a method inside the world (Game1) to tell the world to move the legs around, which is no better.  A better approach might be to make a dog class (a SpriteManager which is subclassed from GameComponent) which composes a list of  sprites as a private field.  If the SpriteManager is added as a component to the Game1 instance, the Game1 Update method's call to base update will also call the Update method of the SpriteManager, where you can iterate through your list to update each sprite.

 This may not be the best or only way of doing things, but I think it works as an example to demonstrate a method of decomposing the functionality of your program to decide what should be encapsulated as a class.

Let's also not forget the loss of polymorphism. Encapsulation is only one aspect of a class, but I feel polymorphism is a more powerful reason to use classes. I have never programmed any game without heavy use of polymorphism. Game code would look pretty ugly if you just used the Game1 class and just made methods for everything. My mind does not even work without polymorphism anymore. It's the only way I think. Classes and OO is the only way I think.

qc zackf:

Could you by any chance mean the difference between a Struct and a Class?

Structs are value types and Classes are reference types. If you pass a struct as a parameter into a method, the method code will actually be using a copy of the struct's values. Change those values in the method body and the original struct object that got passed in will not change.

Replace that struct for a class in the same situation and the modifications that the method makes to the class will impact the original object that got passed in as a parameter.

Structs, like all value types, are cheap to make and cheap to throw away. Classes are more powerful tools, but also more expensive to create and throw away, especially in 360 development.

Usually structs are made up of very simple components (a handful of integers and vectors, perhaps) so copying the struct can be healthier for your game's performance than creating a reference for it. In the instances where it is not (for instance, using the same Matrix value in many calculations at a time) you can reverse its behavior by using the ref keyword in your method parameters.