Static methods

[carderne]

This is more about convention than actual help. i.e. My program works fine, I just want to know if how I've coded it is acceptable. Note my descriptions are simplified for ease of understanding.

I have a Main class, which is a JFrame GUI and which has a main method. I also have a Func class, which has all of the methods to perform functions, and I have a Song class, which has lots of getters and setters.

The Main class runs, and when a button or something is clicked, a method is called from the Func class. Thus I have made every method in Func static, as I don't require objects of it... So all the methods are called with a class reference: Func.doSomething(). Is that considered good programming practise or whatever? The Song class is not static, as many objects of it are made.

Then, the part I'm not so happy about. The Main class creates an object of a fourth class, called Output, which is responsible for playing back songs. So it creates an object of this class and when a button is clicked, calls the play method: musicObject.play(). This is fine, but then, as the song progresses, this object/class has to make alterations to some components in the Main class. So these components have to made static, surely for this purpose... It just doesn't seem right...

[Eranga]

You say that for the fourth class you have an object, and you want to use that object in different events of the main class. Right?

So why you cannot use an object on a static block of the main class.

[carderne]

Sorry, I don't follow your question.

The fourth class (Output) is created as an object in the Main class and used in varioug methods, that's fine. But then I want that object to modify a component in the Main class. What I want to know is, is it considered good programming practise for an object to be modifying the class that created it? The Music class has a listener that periodically updates a JProgressBar in the Main class. To do this, the JProgressBar must be static, so the method in Music can go: Main.progressBar.setValue(someValue). Alternatively the Music class would have to make an object of the Main class... But that makes no sense at all.

Basically, my worry is that I'm using 'static' where it isn't really supposed to be used.
Thanks for your advice.

[Fubarable]

My take on this is that if you ask 5 different programmers these questions you'll likely get 5 different opinions. So in that light, here are my amateur opinions that are not guaranteed to be right but only are guaranteed to be my opinions:

I have a Main class, which is a JFrame GUI and which has a main method.

I can't think of any GUI code I've made recently that subclasses JFrame and I've not seen any posted on this or other forums that should subclass JFrame. My recommendation is to try to avoid extending your code through inheritance unless there's a need for and and unless it makes a lot of sense to inherit. Instead it is often better to extend your code through composition. What I usually do is have my main class create a JPanel and make this panel available by public method, then in the main method (which is usually in a separate "Driver" class), I create the main class, create a generic JFrame, place my main class's created JPanel in the JFrame, then pack, position, and display the JFrame.

The Main class runs, and when a button or something is clicked, a method is called from the Func class. Thus I have made every method in Func static, as I don't require objects of it... So all the methods are called with a class reference: Func.doSomething(). Is that considered good programming practise or whatever?

This can be OK if the Func class acts more as a library than as an object (think of the Math class for an example of library). Without seeing the program, I can't tell though. Does the Func class have any "states" that change? Again, tough to say without seeing the program.

Then, the part I'm not so happy about. The Main class creates an object of a fourth class, called Output, which is responsible for playing back songs. So it creates an object of this class and when a button is clicked, calls the play method: musicObject.play(). This is fine, but then, as the song progresses, this object/class has to make alterations to some components in the Main class. So these components have to made static, surely for this purpose... It just doesn't seem right..

I agree, this doesn't seem right at all. I'm almost sure that there is a better solution here without making these methods and fields static.

By the way, I think that these are excellent questions that you are asking.

Good luck and hope this helps.

[Fubarable]

By the way, I think I'd tackle the last issue by using the observable design pattern by having the main class create a listener (the simplest would be a ChangeListener) and then adding that listener to the Output object. Thus whenever Output's state changes, the Main class is notified and can change its display accordingly. This would solve the problem without using static anything.

[carderne]

1. The main GUI
My GUI is created in the default way that Netbeans creates it... i.e. if I click 'new class' and choose 'new frame' (or something like that) it creates a new class that, as you said, extends JFrame. Why is that bad?

2. Func
I could create an object of Func in the Main class, as it is the only class that accesses it... Would this be better? The only season I didn't is that all of the methods just do something and possibly return a value. There aren't any 'states,' except for one field, which is accessed or modified in most of the methods. Is that season enough to make everything non-static?

3. Output object
I like your idea about a listener. I thought that the answer must lie in a listener of some sort, but I don't have enough experience to have known which or how... I'll look up the
ChangeListener and give it a bash. Isn't there some other thing with which you can bind two components/objects? Beans Binding I think.

[Fubarable]

1. The main GUI
My GUI is created in the default way that Netbeans creates it... i.e. if I click 'new class' and choose 'new frame' (or something like that) it creates a new class that, as you said, extends JFrame. Why is that bad?

It forces your class to be something that it may not want to be. What if later you create another GUI and wish to use your current class as a JDialog? Or what if you wanted to make this into an applet? Could you easily do this? If on the other hand you extracted all the logic from the GUI, and then had your main GUI portion create a JPanel as I mentioned above, then the answer would be yes.

2. Func
I could create an object of Func in the Main class, as it is the only class that accesses it... Would this be better? The only season I didn't is that all of the methods just do something and possibly return a value. There aren't any 'states,' except for one field, which is accessed or modified in most of the methods. Is that season enough to make everything non-static?

this is hard for me to answer given my lack of knowledge of your program and my lack of experience. Perhaps one of the experts here will give you a better answer.

3. Output object
I like your idea about a listener. I thought that the answer must lie in a listener of some sort, but I don't have enough experience to have known which or how... I'll look up the
ChangeListener and give it a bash. Isn't there some other thing with which you can bind two components/objects? Beans Binding I think.

I don't know about Beans Binding so I can't answer this, but I have used listeners a lot and have used interfaces quite a bit both with the motivation to keep my coupling as loose as possible.

[carderne]

1. The main GUI
Ok, I see what you're saying. In my case, the logic is very 'GUI specific' - it is 99% button clicks and focus loss and gain... It consists almost entirely of actionPerformed methods, containing calls to methods in Func. For example, when the user clicks 'Add Folder,' a JDialog with a JFileChooses pops up. Main then passes the selected file onto a Func method, which imports the songs. Various JLists are then updated, perhaps a message created, and then the actionPerformed method is complete... So the vast majority of the actual logic is stored o Func; it would be a simple task to create another GUI that uses the same methods... So if I decided to make it into an applet, I'd create the new GUI and continue using the methods from Func. With your idea, would all of the components have been designed into the JPanel? I suppose that is quite an appealing idea.

2. Func
I made it all static before properly understanding the purpose of the static modifier. I've realised a good enough season to make it non-static: say I wanted to make another GUI that used a separate instanc of Func... So I think I'll be making it un-static.

3. Output object
I've figured it out. Let me explain my stupidity. In my output class, I created an object of BasicPlayer (from a package I've downloaded for music playback). To add a listener, I made the Output class implement BasicPlayerListener (the included listener with the package I downloaded) and added it as a listener to my BasicPlayer object. This allowed me to handle all events in the Output class. What I've done now is rather created the listener in my Main class, allowing all events to be handled there. I hope that makes a bit of sense...

I'll post some code samples later.

[carderne]

Well it seems I've solved my worst problem, number 3 in my previous post. I've decided also to make Func non-static, as I should not have made it static in the first place. I'm completely reworking the structure of my classes so this problem should disappear altogether.

The only thing not solved is the creation of my main GUI... I don't have enough experience of swing (Netbeans does it for me) so I don't know how to do what Fubarable suggested...

[Fubarable]

The only thing not solved is the creation of my main GUI... I don't have enough experience of swing (Netbeans does it for me) so I don't know how to do what Fubarable suggested...

which is the best argument that I know of to suggest that you ditch the NetBeans-generated code and dive head-first into hands-on Swing code creation. This is not to say that NetBeans generated code is bad, but that it actively hinders your ability to learn Swing, to learn how to create GUIs that you can change and adapt later if desired. It is for this reason that I discourage Swing newbies from using this "feature".

From reading your posts, I know for certain that you've got the smarts to be able to pick up Swing coding quickly. So why not head to the Sun Swing tutorials and give it whirl?

Best of luck.

[carderne]

Hehe. I had hoped to avoid learning swing, as I can see it is quite tedius; I far prefer logic code, but I suppose it will be better to have more firm control over what my GUI is doing. I've got all of the Sun tutorials on disk, so I'll start going trough the Swing ones.

Thanks very much, and SOLVED.