Suggestions for re-Structuring my Project

[abhishek_s_n]

Hey,
I am kinda stuck with the way I should structure my Project. Was going well till now, but now it seems I'll have to re-structure it.

My project is Peer to Peer chat and File Sharing. It performs device discovery, chat and file transfer.

I plan to implement it using JTabbedPane where one main tab would represent the online contacts and others would be created for each contact as and when needed.

Till now I created my Main file where i created the JTabbedPane with one tab for device discovery. For simplicity, i had created another program altogether for chat (file transfer is yet to be coded).

Now how do I bring these codes together and go ahead?

Should I?
1: Combine the whole chat code in the main file itself?
2: Make calls to the chat program to create new instances everytime and add one panel at a time to the JTabbedPane?
And if anything else, please suggest.

If the solution is 2, please guide me, m kinda stuck.

[JamesCherrill]

Without a long look at there whole thing it's hard to be very specific, but in general:

If you divide your application into smaller and smaller components (classes, methods etc) then each of those components becomes simpler and easier to understand (which is good) until eventually you reach a point where the components are too small and simple. You know you're reached that point when you have to pass long strings of parameters between the methods or constructors.
The theory behind this is "cohesion and coupling" - have a quick look at this: http://en.wikipedia.org/wiki/Low-Coupling_/_High-Cohesion_pattern

For methods typical guidelines say thing say things like: anything method over 100 lines, or with {} nested more than 4 deep should be split up. (Big exception: the tedious init methods that build GUI interfaces - they are intrinsically long)
For classes, each class should represent just one thing. For every program I've seen with too many classes, I've seen 100 with too few classes. Don't be afraid of creating many classes.

[Traps]

Without a long look at there whole thing it's hard to be very specific, but in general:

If you divide your application into smaller and smaller components (classes, methods etc) then each of those components becomes simpler and easier to understand (which is good) until eventually you reach a point where the components are too small and simple. You know you're reached that point when you have to pass long strings of parameters between the methods or constructors.
The theory behind this is "cohesion and coupling" - have a quick look at this: http://en.wikipedia.org/wiki/Low-Coupling_/_High-Cohesion_pattern

For methods typical guidelines say thing say things like: anything method over 100 lines, or with {} nested more than 4 deep should be split up. (Big exception: the tedious init methods that build GUI interfaces - they are intrinsically long)
For classes, each class should represent just one thing. For every program I've seen with too many classes, I've seen 100 with too few classes. Don't be afraid of creating many classes.

To continue on what JamesCherrill said about dividing your application into smaller components; it's considered good practice to have each method to do just one thing. That way it's easier to build upon your program, it's more scalable and the readability will improve.

For instance, say you have a method that declares and initiates an array, fills the array with (pseudo-random) data, loops through the array and scans for a predetermined value, and then nulls the array index at the index of the predetermined value. Then it would be a good design to split this into a method that declares, initiates and fills the array and a method that loops through it, scans it, and nulls the element at the index.

[abhishek_s_n]

making methods is ok, i have many methods doing many different tasks.
The problem is classifying into classes.

[Traps]

You can apply the same thing when making classes too. Every class should only do one thing/represent one thing. An animal class for instance should only represent an animal. A chat program (yours for instance) could be divided into socket-handling, client-handling, and the actual chat (excluding MVC pattern etc.)

Neither of your two points are quite right to be honest. Your program should definitely not be just one big file. But neither should you make a program that continuously creates a new instance every time a new panel is added - what would happen if I'd open 1000+ panels at the same time (it would get really slow if you don't get a heap overflow).

[abhishek_s_n]

hmm.. exactly. Thanks for your help.

[JamesCherrill]

...neither should you make a program that continuously creates a new instance every time a new panel is added - what would happen if I'd open 1000+ panels at the same time (it would get really slow if you don't get a heap overflow).

Let's be sensible here. Each panel will involve a number of instances of Swing classes, so anything you do with your own classes will be pretty much irrelevant. As for 1000+ panels - why don't you leave that problem until something suggests you will encounter it. How many panels do you expect?
Remember also that in the end you have to create enough "stuff" to handle the requirements of the application. Much of this "stuff" will have multiple instances. The smaller your classes, the less the redundant "stuff".

Here are some of the classes I'd expect to see in an app like this:

Client:
Main class - app startup and controller (one instance)
Network comms class - handling sockets, connections etc (one instance)
Main window (one instance)
Conversation panel (many instances)

Server:
Main class - app startup and controller (one instance)
Socket listener (one instance)
Connection handler (many instances)
Main window (one instance)
Conversation panel (many instances)

Plus numerous inner classes for ActionListeners etc

... but when developing the code there will probably be other service classes that emerge from the detailed design, such as (maybe) User - encapsulates info about user identity/logon/rights etc., Conversation - encapsulates info about who is talking to who via which connection.