Each week I'll be combing through the #HelpMeCode hashtag on Twitter and looking for questions that I believe I can help answer and would benefit from a deeper dive than the Twitter platform offers.
Today's Tweet:
Liquid error: internal
My post today is in response to a query from @rforjoe. He is wondering how to access the methods in a class from classes in another package in Java.
Hi, so struggling to get my head around this. If I have classes (pages)and i create a class (MenuNavigation) in another package which contains methods I want all the classes to have access to. What do I do?
Great question Richard! There's really two possible answers, and we'll explore both here.
The first way, to simply address the question you asked head on: How do I call all of those methods from classes that are in a different package? It's easy enough to do. We need to import that class (MenuNavigation) into the classes that we wish to call them from. After we've done that we can instantiate a new instance of MenuNavigation and execute it's methods.
Note that the import statement requires a slight addition. Namely, we have to refer to the remote class by a fully qualified name. We include the Package name in the import statement like so:
import Actions.MenuNavigation;
Later in the twitter thread user @Duiker101 identifies that the class structure as displayed may well be suited for a Static class implementation. But what exactly is as static class and when should you use one?
Put as simply as possible: A Static class is a class that does not need to be instantiated. This might fly in the face of what you know about Object-Oriented Programming. After all, don't ALL classes need to be instantiated to an object before they can be used? I certainly did in my example above. The line
MenuNavigation nav = new MenuNavigation();
Does exactly that. It creates a new instance of the MenuNavigation class and assigns that instance to the 'nav' variable. What is a class without an instance anyways? I often describe Classes like architectural blueprints. They describe how to build a house, but you can't live in one.
Sometimes we don't want multiple copies of our instances out there. Or we don't want the possibility of accidentally creating multiple copies. As an example consider a class of Configuration variables. It might read values from a file when the program is first launched. It might also re-read updated values at various points during the execution of our program. With a typical setup we would have to instantiate that class before we could load values into it which means we have the potential problems of both destroying it before we're done with it, thus losing our values, or creating multiple instances of it with different values. Yikes!
With a Static class there is actually one, and only one, instance of our class created. It's done behind the scenes without our involvement, and it allows us to access the class methods and properties without every instantiating it again. We don't have to worry about destroying that instance too early, because we can't! This solution is ideal for Richard's configuration above as well. Assuming the Navigation Menu is loaded once when the program launches and never changes it's functionality then it's a good candidate for a Static class.
Declaration for a Static class in Java is a little more complex. It cannot be a "root-level" class, it must be a sub-class. So for Richard's example I've modified it to have a main class named 'Menu' defined as a public class. My Static class is a sub-class of that root-level class defined with the 'static' keyword. The methods I wish to access must also have the static keyword in their definitions.
Having done that, I can now reference the MenuNavigation class in my HomePage class without the instantiation. When this program executes Java will create the instance for me and manage it and make it available when it's requested.
So that is how and where you might use a Static class in Java. Bear in mind this applies across any OOP language that supports Static classes including C#.
*Find all of Ben's training content here, at CBT Nuggets - http://learn.gg/ben-finkel *
Top comments (2)
Important to keep in mind that static classes can be difficult to test.
Great point Ross! It’s easy to get yourself into trouble although I would argue they’re not difficult to test if you’re careful about their implementation. Too often you end up (as I did in my example) having a hard coded dependency on that static in your method which prevents it from being mocked.
One solution is to pass your static into the methods that rely upon it as a parameter, making it mockable and solving a common unit testing trip-up.