Showing posts with label methods. Show all posts
Showing posts with label methods. Show all posts

Monday, 26 September 2011

Java: Static Variables and Methods

    We know about instance variables and methods. These are the variables and methods that belong to an object, a particular instance of some class. On top of this, Java supports the use of variables and methods that belong to the class as a whole. These are the static ones.

    This class sure is getting used a lot. Here, I've declared a static variable as a counter. Since this belongs to the class and not any particular instance, incrementing it in the constructor increments the count on each new object I create.

CLICK ME SO YOU CAN READ ME!

Probably could have shown the effect with fewer items, but still. You can see that for each new object we create, the counter increases by 1 on each item. Fun times. Good for keeping track. If count wasn't static, on each object initialization, it would be 0, and you'd get a whole bunch of 1's, which is fairly useless. The general point is, static variables are accessible by any instance of an object, and it changes it for all other instances as well.

    You can have static methods, too, and we see that "main" is one, they more or less aren't used except for main, though, as far as I can tell, but its there if you need it for some reason.


    Tomorrow, I'll do a double update to make up for that missed update a couple nights ago, but for now,
that's it for tonight.Questions welcome! Comment, follow, subscribe, share etc, and see you tomorrow!



    And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here (fixed), and feel free to throw loads of criticism at us. 



Monday, 19 September 2011

Java: Method Names, Scope

    So we know a typical java program will end up making use of multiple classes, some being programmer-created, and a bunch being used from the JDK library. Some thought needs to be put into how the method names are used in all these classes and how they coexist.
    (Aside: I just spent the last half hour typing out the completely wrong thing.)
    We know from before that, as long as variables are declared in separate scopes (such as 2 different methods), they can have the same name. Well, the same general principle applies to methods themselves, which works fine as long as the methods are actually in different scopes. GenericStack.pop() and IntStack.pop() for instance, differentiate between the 2 methods based on which object is calling it, even though in this case, there's not a difference.

Overloading Methods:
    It turns out that methods are not identified by their name alone, so we don't strictly need to have different names for every method inside a specific scope. Surprise! A method's identifier is a combination of the method's name as well as the amount and type of parameters it takes. This opens the way for having a few methods that differ oh-so-slightly within the same scope. This nifty little trick is known as overloading. Overloaded methods don't take into account return values, so different value types can be used with them. Overloading is pretty serious business with respect to object oriented programming, since it allows us to have different implementations of a method depending on the amount and values of parameters provided. Think of several add methods to a stack of unspecified type.


    That's it for tonight. Comment, follow, subscribe, share etc, and see you tomorrow!


    And as part of a shameless plug for a friend, if you're interested in classic movies/books/music, visit his site here, and feel free to throw loads of criticism at us.