What is a method exactly?
Author
Okay, I am trying to teach myself C# and I have a question. What EXACTLY is a method and what is its purpose?
I know methods are associated with classes, and I believe that a class always requires a method. I understand how the Main method works... I am just looking for a general, non-textbook definition of a method in relation to how it is done in C#.
I've spent hours Googling this and all I've gotten were textbook answers that really didn't help me any. Any help would be greatly appreciated. I feel like the answer is on the tip of my tongue, because I understand how Namespaces, Classes and Statements work, and I understand (generally speaking) how methods are associated with classes and statements.
Anyone who can at the very least point me in the right direction has my eternal and undying gratitude.
A method is simply a set of instructions which belongs to a class and which can be executed by being called from within another method.
There are class methods, such as Main(), which require the 'static' keyword in C# and can be executed without requiring an actual instance of the class they belong to, and there are object methods, which are executed on a class' instance and usually perform some operation on the object.
The instructions within a method normally serve one specific purpose, which is a simple and compact as possible, so the method can be reused in multiple places. Complex operations are created by combining simpler methods.
-Markus-
There are class methods, such as Main(), which require the 'static' keyword in C# and can be executed without requiring an actual instance of the class they belong to, and there are object methods, which are executed on a class' instance and usually perform some operation on the object.
The instructions within a method normally serve one specific purpose, which is a simple and compact as possible, so the method can be reused in multiple places. Complex operations are created by combining simpler methods.
-Markus-
A method is a combined statement block and namespace, typically - but not necessarily - inserted into the namespace of a class and associated at runtime with an instance of that class. The former allows for the allocation of static, dynamic and reentrant objects; the latter allows for the modification of class and instance members.
The Tao of Method.
In the real world, there are a lot of things. And everything has a logical type; the answer to "what kind of thing is this?". Perhaps it's a number, or an amoeba, or a grapefruit. And some of these things are alive.
In the OO programming world, "living things" are objects. They contain other things (cells, bits of DNA and so on), which may recursively contain other things - all the way down to primitives (the primordial stuff of the OO programming universe). Some OO languages do a better job of encapsulating the primitives than others (breathing some life even into individual particles), but that's beside the point. We can also have objects that refer to each other (via 'references' or 'pointers'), without actual containment.
The object's class is its type. Alice holds up an amoeba. "What kind of thing is this?" Bob replies, "It is an instance of class Amoeba." And it is alive. The class description indicates everything that defines what it means to be an amoeba, and also provides the blueprints for creating an Amoeba out of nothing but pure allocated memory (energy? unspecified matter?) - the constructor(s).
In languages like C++ which don't take OO too seriously, we may find free functions - these describe "things that can happen" in the program's universe. A method has the same purpose of describing an action, but it is logically bound to a thing. Within the class Amoeba text, we find the code for an Amoeba method. This is not merely a "thing that can happen"; it is a "thing that an Amoeba can do". When it happens, an amoeba must be involved somehow - it is the one doing the thing.
In the main program code - we play God, and this is our script - we create amoebae and tell them to do things. Amoebae aren't very interesting creatures; basically all they do is split(). But we can say "here is an Amoeba a;" and give it that name "a", and what happens in the compiled code is that a bunch of memory gets pooled together - just enough - and then it is turned into a new Amoeba. And then we can tell it to split, like "a.split();" and something happens. It is not "a splitting is occurring, of this amoeba". It is "this amoeba is splitting". Because it can, and we have told it to.
Within the code for the method, we may assume we know which amoeba is being talked about. When we refer to a cell membrane, we need not say which amoeba it belongs to. It belongs to the amoeba which is splitting. In most of the languages you are likely familiar with, "the amoeba which is splitting" is called "this" within the method code (in C++, "this" is a pointer to that amoeba). Usually can leave the name out altogether. However, some living things "act passively". A suicidal creature may ask some other creature to kill it. It obtains the name of its murderer - let's call that creature Fruny, because I've been up all night and I find that amusing - and provides its orders: "Fruny.kill(this)".
But in the deep workings of the universe, there is no understanding of the consciousness of living things. There is only interaction of particles. Thus our requests for an object's method are translated behind the scenes into ordinary functions; our living thing becomes just another parameter. "An amoeba is splitting" once again becomes "A split occurs of an amoeba". We can code on this level, too - but it is like an assembly code listing pointed up at the sky: if you fix your eye on the opcodes, you miss out on the heavenly glory - and the meaning of this great cosmos called OO. (Oh, and a bunch of other stuff that the compiler becomes able to do for you - to keep you from messing things up, and to make sure that things are consistent and organized.)
In the real world, there are a lot of things. And everything has a logical type; the answer to "what kind of thing is this?". Perhaps it's a number, or an amoeba, or a grapefruit. And some of these things are alive.
In the OO programming world, "living things" are objects. They contain other things (cells, bits of DNA and so on), which may recursively contain other things - all the way down to primitives (the primordial stuff of the OO programming universe). Some OO languages do a better job of encapsulating the primitives than others (breathing some life even into individual particles), but that's beside the point. We can also have objects that refer to each other (via 'references' or 'pointers'), without actual containment.
The object's class is its type. Alice holds up an amoeba. "What kind of thing is this?" Bob replies, "It is an instance of class Amoeba." And it is alive. The class description indicates everything that defines what it means to be an amoeba, and also provides the blueprints for creating an Amoeba out of nothing but pure allocated memory (energy? unspecified matter?) - the constructor(s).
In languages like C++ which don't take OO too seriously, we may find free functions - these describe "things that can happen" in the program's universe. A method has the same purpose of describing an action, but it is logically bound to a thing. Within the class Amoeba text, we find the code for an Amoeba method. This is not merely a "thing that can happen"; it is a "thing that an Amoeba can do". When it happens, an amoeba must be involved somehow - it is the one doing the thing.
In the main program code - we play God, and this is our script - we create amoebae and tell them to do things. Amoebae aren't very interesting creatures; basically all they do is split(). But we can say "here is an Amoeba a;" and give it that name "a", and what happens in the compiled code is that a bunch of memory gets pooled together - just enough - and then it is turned into a new Amoeba. And then we can tell it to split, like "a.split();" and something happens. It is not "a splitting is occurring, of this amoeba". It is "this amoeba is splitting". Because it can, and we have told it to.
Within the code for the method, we may assume we know which amoeba is being talked about. When we refer to a cell membrane, we need not say which amoeba it belongs to. It belongs to the amoeba which is splitting. In most of the languages you are likely familiar with, "the amoeba which is splitting" is called "this" within the method code (in C++, "this" is a pointer to that amoeba). Usually can leave the name out altogether. However, some living things "act passively". A suicidal creature may ask some other creature to kill it. It obtains the name of its murderer - let's call that creature Fruny, because I've been up all night and I find that amusing - and provides its orders: "Fruny.kill(this)".
But in the deep workings of the universe, there is no understanding of the consciousness of living things. There is only interaction of particles. Thus our requests for an object's method are translated behind the scenes into ordinary functions; our living thing becomes just another parameter. "An amoeba is splitting" once again becomes "A split occurs of an amoeba". We can code on this level, too - but it is like an assembly code listing pointed up at the sky: if you fix your eye on the opcodes, you miss out on the heavenly glory - and the meaning of this great cosmos called OO. (Oh, and a bunch of other stuff that the compiler becomes able to do for you - to keep you from messing things up, and to make sure that things are consistent and organized.)
Author
Thanks guys. I think I understand now.
Do any of you have a suggestion for an easy to understand, non-textbook like tutorial for C#?
Do any of you have a suggestion for an easy to understand, non-textbook like tutorial for C#?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
