# [java] when is it the time for separating a single .java into packages and interfaces?

This topic is 5067 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

this may sound odd for some... (but as im natively a pascal coder...) yeah thats right, my very first language was pascal, followed by delphi, c, c++, java. i took a look into C#, but never went into it. in pascal, youd want to create "unit" files when your code was longer than 3000lines. (the compiler was unable to compile more than 3000 lines at a time). in delphi, it would automatically put every form source in a different file, and even if you wanted, you couldnt have it in the same one. and you would create .dll files when you have different projects running the same routines. in C in general from what ive seen, it really depends on the programmer... ive encountered a few whod split everything, and some whod always make huge single files... now that you know my backgrounds, re-read the title: when is it the right time to split a single .java into packages and interfaces? what i mean is: how better for performance would it be? (not thinking about team related stuff, as im the only coder in my team haha) my only real reason to go thru the trouble of splitting the code: - its a damn long file right now, where i tried to follow a logical sequence for ordering variables, objects, swing components, classes and methods, but as it does a lot of nearly-unrelated tasks atm... IE: accessing files in disk, communicating with a server, warning pop-ups for the users, generating parts of the GUI from users responses in real time, not to mention a complex GUI, with a few different JFrames, and many different "states" of the main JFrame, according to what task the user may be executing... and a HUGE "import" part... importing many many many many packages... you have to admit that to have all that in the same file is ugly-coding... and... well its becoming hard to manage. as in: when i have to scroll up to this *specific* part of the code, finding variables, blah blah... but i do have some static methods, and i use a single "action performed" method to manage all gazillions of buttons, and this is managed by a "command list"... now, having them in packages: - will performance be the same? - will i need to add all package files into the "instalation" dir (like needing to have a few .jar files in the same dir as the main executable) - is there any REAL advantage of having a few different packages rather than a single file? (the organizing part wont count as advantage, ok? cuz despite it being hard to manage, its not impossible to have an organized code in a huge file) -would it be faster to have the fired actions for the buttons run from different packages rather than iterating thru a list using a switch?

##### Share on other sites
Hmm, sounds to me like your not too familiar with the whole point of OO programming.

(Very) Basically, your program should be designed such that each class fulfills a specific role. For example, one class would work on server communication, another on rendering the GUI, another on reading input from the GUI, etc.

There is no performance hit at all from putting files in different packages. The point of packages is to logically group related classes, e.g. all your GUI classes might go in one package. Packages in Java pretty much means just having different classes in different folders, they're not the same as C++ namespaces.

Quote:
 will i need to add all package files into the "instalation" dir (like needing to have a few .jar files in the same dir as the main executable)

You can either wrap each package into a different JAR, or wrap the entire application into the one. It makes little difference to your program, the only reason you might want to wrap packages in different JARs might be if you want to use those packages in different applications at a later date.

##### Share on other sites

How many classes do you have? And of them, how many are nested classes?

##### Share on other sites
Quote:
 Hmm, sounds to me like your not too familiar with the whole point of OO programming.

I have good knowledge of OO programming... but as i said, my OO backgrounds come from Delphi. the bad part is the "lybrary building" part in delphi is very automated, as it automatically picks which part goes in which file, and you dont have a lot of freedom when building, and this "lack of freedom" from delphi killed my ability to "design well" in Java, when i have to define those things on my own, and i have enough freedom to design as I want. besides, im an electronics engineer. i didnt have good programming skills subjects at university, as it wasnt oriented in software building... so all my programming knowledge, or at least 95% of it comes from teaching myself. the result is that even if i have good knowlegde of OO design, I dont use any "academic approach" when designing. (which i recognize as very bad, and am trying to change). but most of time, if it compiles, im satisfied with it. i dont build code for any company atm... i code for my own fun, more likely, and i have fun building games :P whenever a "professional programmer" sees my codes s/he will act like: "ewwwwww does that sh*t even compile??" :P

Quote:
 I'm afraid to ask, but...How many classes do you have? And of them, how many are nested classes?

hmm i wont show the code here,ok? this app is more or less some "experiment" for my mmorpg. like: ive come up with code that works in the manner i want it to work, but it recently looks ugly, is disorganized, and its really not presentable in the programming community. but after all, it runs, and it has shown good performance so far. but when i go for a final version, i want to look "properly"

I currently have: 4 classes, 2 of them have no more than 4 nested classes, and the nested classes have no nested classes. in those 4 classes i have at least 8 methods in each, plus 3 or 4 methods that arent in any class, as they are "common" to 2 classes. I have 3 GUI-generating methods that return JComponents,and display on the same JForm, due to run-time changes in the GUI. all of them implement "ActionListener" and theres is only one "ActionPerformed" method thats common for everything that implements "ActionListener". the same goes to the other listeners I have: "focusGained", "focusLost", "valueChanged" and "propertyChange" listeners.

as i know that Swing has issues around "thread safety" and I do run at least 2 threads at a time, i run mostly everything thru the event dispatching thread. but only one of the threads displays a GUI (made of swing components), the others are server conenctions listeners/parsers, and display the stuff they need on a JTextArea, when needed be.

well... i know this will be scary for you guys, but my "import" section goes like:
import java.awt.*;import java.awt.event.*;import javax.swing.*;import javax.swing.event.ListSelectionEvent;import javax.swing.event.ListSelectionListener;import java.awt.print.*;import java.io.*;import java.nio.*;import java.nio.channels.*;import java.nio.charset.*;import java.beans.PropertyChangeListener;import java.beans.PropertyChangeEvent;import java.util.*;import java.text.*;import java.util.AbstractList;

and yeah, i do know its getting too big!

##### Share on other sites
Quote:
 Original post by ElehisieI currently have: 4 classes

All in a single file?

##### Share on other sites
is it really THAT bad to have them in a single file? o_O

##### Share on other sites
The accepted "Best Practice" is to have one class or interface per source file, and that source file has the same name as the class/interface. Now, if I'm being lazy I might let a very small interface slip into a file that already has a class, but only if I'm being VERY lazy.

I highly suggest you stick to the one-file-one-class rule.

Get rid of the nested classes, move them to their own files as full classes. Just really bad design. Nested classes and anonymous classes cause problems when debugging. ESPECIALLY anonymous classes. If I could find the person that thought it a good idea to include anonymous classes, I would beat them into jelly.

you also seem to be using the words pacakge and file interchangeably. They are most assuredly not the same thing. While the Java package structure is tied to the file system, a package should be thought of as merely a set of related classes and should not be thought of as files residing in the same directory.

Your imnport list is fairly typical of a java application. Don't worry about it. I let eclipse organize my packages automatically.

##### Share on other sites
ive been thru a lot of the tuts in java.sun.com, and they are all very basic (and i mean too very basic) or really not deep enough (imo).

---> well im gonna search for some good designing resources later :)
(when im not at paying job) for now, i really appreciate the attention, guys!

(and that "best practice" thing really explains why some code ive been running into looks so incomplete)

##### Share on other sites
Uhhh... I thought you could only have one public class per file, and it had to be the name of the file. What am I missing?

##### Share on other sites
Quote:
 Original post by KevinatorUhhh... I thought you could only have one public class per file, and it had to be the name of the file. What am I missing?

I think you miss nothing. The Java compiler (Java 1.5 from Sun and also those I've used before) complains if you violate the mentioned rules. (However, you could have inner classes as much as you want, of course, but that wasn't the question.) So, even if some other compiler accepts such stuff, it will not be portable.

EDIT: An excerpt from the man page of javac:
Quote:
 man javacSource code file names must have .java suffixes, class file names must have .class suffixes, and both source and class files must have root names that identify the class.

[Edited by - haegarr on December 5, 2005 11:57:36 AM]

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 11
• 15
• 21
• 26
• 11