Instance methods, static methods, class methods: Difference between revisions
Jump to navigation
Jump to search
m (Helpful moved page Instance method, static method, class method to Instance methods, static methods, class methods) |
mNo edit summary |
||
Line 1: | Line 1: | ||
<!-- | <!-- | ||
(In most languages, the way you will define all of these is considered part of a class) | |||
==Instance method== | |||
For context, many functions defined on a class will be considered '''instance methods''': | |||
defined on a class, will later work on an instance of that same class handed to them. | |||
you can call them on an instance | |||
they will implicitly ''always'' be working on a, | |||
In some languages, the fact that you always hand an instance into an instance method is expected to be explicitly written out, e.g. in python: | |||
<syntaxhighlight lang=""> | |||
class Foo: | |||
# (ignoring the constructor and how 'name' comes to be) | |||
def bar(self, name): | |||
self.name = name | |||
Foo.bar('quu') | |||
</syntaxhighlight> | |||
Other languages consider this so obvious that the syntax doesn't make your write that, e.g. in Java | |||
<syntaxhighlight lang=""> | |||
class Foo { | |||
# (ignoring the constructor and how 'name' comes to be) | |||
public void bar(String name) { this.name = name; } | |||
} | |||
Foo.bar("quu") | |||
</syntaxhighlight> | |||
That is not the only thing you ever want to do with a function. | That is not the only thing you ever want to do with a function. | ||
==Static method== | |||
you can call them on a class | |||
they don't necessarily working on an instance of that class, | |||
Another is '''static methods''': | Another is '''static methods''': | ||
: a function stuck on a class, but do ''not'' take an instance | : a function stuck on a class, but do ''not'' implicitly/inescapable take an instance | ||
: nor can they access the class definition directly | : nor can they access the class definition directly | ||
: these are often to stick some utility functions on an class rather, than just ''near'' it in a module - | : these are often to stick some utility functions on an class rather, than just ''near'' it in a module - | ||
Line 22: | Line 53: | ||
::: Just how necessary that is to cleanliness may depend on how much you split out your modules and/or how much you fetishize OO. | ::: Just how necessary that is to cleanliness may depend on how much you split out your modules and/or how much you fetishize OO. | ||
For example | |||
* MyString.length( mystring_instance ) | |||
: actually a bad example, in that assuming it only works on that instance anyway, you might as well make it an instance method so you can do mystring_instance.length() - there often isn't a strong reason to do it either way. | |||
* MyString.from_regular_string( string_instance ) | |||
==Class method== | |||
* [[class methods]] are defined on a class, and do not take an instance, but ''do'' get a reference to that class, meaning they can fetch class variables (note: not instance variables) | * [[class methods]] are defined on a class, and do not take an instance, but ''do'' get a reference to that class, meaning they can fetch class variables (note: not instance variables) | ||
:: ...and could potentially alter that class | :: ...and could potentially alter that class | ||
:: ...but more | :: ...but probably more usually used for things like [[factories]]?{{verify}} | ||
:: from the context of instqance variables, self.__class__ often lets you cheat you way out of needing these (but it's not as clean) | :: from the context of instqance variables, self.__class__ often lets you cheat you way out of needing these (but it's not as clean) | ||
:: Not used much unless you do some meta-modelling, or need a reference to the class but not an instance. | :: Not used much unless you do some meta-modelling, or need a reference to the class but not an instance. | ||
--> | --> |