Yes, absolutely - make each tab it's own class. When in doubt, err on the side of having more classes. Since a tab is usually a container for other UI controls, each of your tab classes should be a JPanel (ie, it extends JPanel); even if it contains just 1 control today, make it a JPanel.
In addition to the great advice given above, here are some more suggestions:
1.
Identifying classes: What should be a class, is a problem I think all of OOP learners in every language face when starting off (atleast I did).
A good way to find out classes is to write a textual description of how to achieve each user end goal in your app, and then look for the nouns in that description.
This is called
Noun analysis (one more
tutorial here).
It's a good technique for OOP beginners to find out classes. Good news is, with practice, this comes naturally.
The idea is, write the descriptions in simple terms, not technical terms - like you're explaining to another person. Then look for the nouns.
An example: "For creating a new inventory order, user should open the inventory management window, select the new inventory page, fill the fields on that page, and save inventory. System will validate the fields, and save the new inventory in inventory database".
Nouns (and potential classes): Inventory, Order, Inventory management window, Inventory page, Validation, Inventory database.
Such analysis will never give you all classes (because things like code reuse and abstractions are programming concepts and not everyday speech concepts), but it'll give you most of them.
2.
Packaging: Split your app into at least 4 layers in terms of packages (this is one way of splitting. Another way is to split first by function and then create model-view-controller-data subpackages under each function - this is suitable for large apps where each function is sufficiently independent of other functions).
com.yourapp.model - contains all bean and business logic classes
com.yourapp.view - contains all UI (Swing) classes and related classes
com.yourapp.controller - this I'll explain next point
com.yourapp.data - contains the DAO and persistence management classes
3.
MVC architecture: Follow the
MVC (Model-View-Controller) architecture for each and every user end goal that your app caters to. This is a great architecture for desktop apps like yours, and it keeps your app flexible enough to meet UI requirements in future.
In MVC, for every goal ("use case" in technical terms), atleast 4 classes should collaborate:
The "Controller" is a class that is like a director for workflows - it directs the steps of the goal in the required sequence and coordinates between the UI and the logic. The advantage of having a controller is that if app executes same action for different UI elements (ex: Save in menu, and Save button in toolbar), then code need not be repeated in each action listener.
The "Model" is a class (or more usually a set of classes) that is/are responsible for business logic. This set consists of bean classes and service or business logic classes.
The "View" is a (set of ) class(es) that is/are responsible for creating the UI elements, listening to user actions, showing error messages.
The "DAO" or data classes are responsible for saving and reading data from a persistent store (a JDBC database in your case).
The collaborations among MVC classes all follow this
pattern:
1) User does some action (clicks a menu, clicks a button, etc)
2) An action listener in the view class(es) receives this action.
3) The action listener calls a method in its respective controller class, that sets off a sequence of processing actions
4) The controller may ensure some preconditions (for example, before creating a new request, inform one or more UI elements to disable themselves until processing is finished; or check that some other processing that may lead to data inconsistencies is not running).
5) Controller delegates the processing to a class in the model layer.
6) The model does some processing using its business logic.
7) The model informs a DAO class in data layer to persist to /read from database.
8) Model may populate some beans which contain information read from database, to be displayed back to user. Or it may contain error information if there was an error.
9) Model can now directly notify a view about results or errors using the
Observer/Listener pattern, or it can do so via Controller by returning beans back to Controller.
10) If model returned data to controller, Controller passes it along to the view to be displayed.
11) If the last action resulted in some fatal error, then controller can inform all other components to cleanup (like closing DB connections) and finally exit the application.
4.
Sequence diagrams: Another good tool to think about flows in your app (ie, which class should do what?) is to use sequence diagrams to find out methods and responsibilities (especially for business logic classes). A simple tool you can use for creating sequence diagrams is
http://www.websequencediagrams.com/
5.
OO axioms: There are many other good axioms in OOP - code to interfaces and not implementations(especially true for service classes); even if current requirements require just 1 object
of a type, code in such a way that in future n objects of that type can be handled, etc, etc.
But the best way to understand why these axioms are priceless, is to not follow them at all the first time! It's hard to explain why you should follow them, if you haven't experienced the problems of not following them and doing OO wrong. So consider these axioms only in your second stage of learning OOP.
6.
Starting off: To start with, follow all these principles for completely implementing just one use case - that itself will throw up lots of issues and questions. Get that single use case implementation reviewed by a colleague - they will, for sure, tell you some UI changes ("I'd like this to be a table, not a list!"). Try incorporating those changes - that'll throw light on which parts of your OO design and classes are not flexible enough at the moment. The goal of OOP is flexibility.
7.
Avoid paralysis by analysis: Lastly, I think it's very easy to end up in a Paralysis-by-(OO)Analysis situation for beginners. So think up one way of framing classes using the broad principles mentioned above, don't worry if it's THE complete and perfect design - there's no such thing, jump in and implement that design, it'll have some problems for sure, then solve those incrementally by refactoring.
Welcome to OOP
2
