We Keep Coding

How to organize java classes?

I am building a simple POS for my business. I own a little restaurant and would like to make my life easier. I have a class (main menu) that extends JPanel, this class has layout BorderLayout. The menu has a set of panel (NORTH) with button, a JList(WEST), another panel with buttons(CENTER) to change the submenus(EAST), and another buttons(SOUTH) for removing and/or modifying items on list.
When I click on modify (a button on the south panel) another panel should appear. This panel is for the most part the same as the main menu. It has a menu on the north, a list on the west, etc. The part that differs is the actions the buttons on the north and the buttons on the south perform.
My question is:
1) should I create a general class and extend to create this two menus I need
2) should I add an inner class to each extended class for the corresponding functionality of the buttons or should I create external actions.
I am always confused about how to treat events. Create external classes and pass listeners to classes or to use nested classes (but sometimes I find too many nested classes).
If you need me to post the code let me know. Is a little long, this is why I did not post it!

Much of this is opinion based, but here goes anyway...
I would suggest creating subclasses for the different menus, each extending a abstract class defining the common elements. Have them in the same package.
As for event handlers, that's trickier. Sometimes an even handler is only used in one place, in that case, an anonymous inner class (or lambda in Java 8) is the best approach. But if the same handler may be used for different events, then remember the DRY principle, and use a separate class.

Creating a GUI Class in Eclipse

What I'm thinking of doing is creating a class for my little subview, so I can use it over and over again. Specifically, in my project, I need a colored rectangular and a label, and between those subviews those are the ones gonna change. Thus, I want a class that represent that two components as one component.
I'm trying to use swing. Before, I used acm package which gave me convenient way of doing it, but I can't solve that problem with swing. So, the problem starts here, I couldn't figure out how to create a custom GUI class for a subview.
I want to put them in a for loop later, so I want to handle the case in once rather than writing for 20 times manually.
Any help would be appreciated,

Create your custom class so that it extends a JPanel. From there, you can add your common subcomponents, which sets each one up by passing parameters through the constructor, and then implement any common behaviours with methods on that class.

You could try Window Builder plugin for eclipse for drag and drop editor. You could try to figure what's going wrong by organizing you objects.

Syntax of establishing JFrame. Which is correct?

I'm fairly new to programming and definitely new to Java. I'm teaching myself before I begin courses this fall in computer science and I have a curiosity about syntax that I have seen from two different authors.
In one book, a JFrame is usually established by making the class an extension of JFrame
public class MyClass extends JFrame {
etc
However, another author, and also questions on this site usually establish a frame inside of the class as such:
public class MyClass {
JFrame frame = new JFrame();
Firstly, what are the advantages of one over the other?
It seems to me, and I'm hardly an expert, that making a class an extension of JFrame would make it easier to set parameters of the frame and also to add components to it.
IE in the extension format, you simply say
add(component);
However, in the other format, on must type:
frame.getContentPane().add(component);
which seems more tedious.
Can someone please explain succinctly the reason behind this or if it is simply a matter of preference. I have looked into this and have been unable to get a straight forward answer.

There are philosophical and practical reasons many (including I) prefer the latter:
Prefer composition over inheritance in general.
Only extend a class if you plan to alter its innate behavior (i.e., override one or more of its methods).
By not extending JFrame, it is easier to create classes that maximize cohesion and minimize coupling, and to write clean MVC-based code. A more important example of this concept is to avoid having your GUI code (your view code) implement any listener interfaces (your control code). It's OK for baby programs, but not for grown-up code that has the potential of getting complex.
By not extending a large and complex class such as JFrame, you reduce the risk of difficult to debug hidden override malbehaviors. Try extending JFrame or JPanel and giving the class a getX() and getY() method to see what I mean!
If you're using an IDE that gives suggestions of methods available to objects of your class, you greatly reduce the number (and complexity) of possible suggested methods if you don't override a huge complex class such as JFrame.
By gearing your Swing GUI's to create JPanels rather than override JFrame, you greatly increase the flexibility of how that GUI can be used. Now it can be placed in a JDialog, JOptionPane, a JApplet, inside of another JPanel as part of a more complex GUI or as part of a CardLayout view swap.... and I can go on and on.
On the same token as above, many of my GUI's do just that, create JPanels, that I can test in isolation by putting them in JFrames in small test programs before adding them to the greater whole of the application.

Traditionally you're not creating a special type of frame, so you shouldn't extend JFrame.
You're creating a JFrame and putting content in it, so the latter method is preferrable.
I.e. it's from an object oriented point of view it's cleaner to USE a JFrame, instead of extending one.

Java: Creating a GUI. Import or Extend JFrame?

I did a GUI by my own which extends a JFrame. And I saw a program code from advanced programmer who imports the JFrame. I might know the difference between import and extend. But what advantage is given by which sort of implementation?

By "import" i presume you mean that your programmer friend's class uses a JFrame whereas your class is a JFrame. I don't think extending a JFrame is "wrong", but my preferred approach is to create and configure a JFrame rather than extending it. If there's really some protected method that you need access to then you might extend it but i'm sure that, in most cases, simply creating and configuring a standard JFrame is right - i have never found a need to extend it.
In other words, by inheriting JFrame with no real need to do that, you're just complicating your system. This is a same argument you would have when choosing inheritance versus aggregation with any other class. To find out what's right, you need to ask yourself if the class you're writing really is a JFrame which is a window widget. I suspect that in most cases you are writing a Swing application which needs a JFrame but which isn't one itself - it's a Swing application with some other purpose.

How to use WindowBuilder to edit a JPanel in an inner class

I would like to use WindowBuilder in Eclipse to construct Swing GUIs. The JPanels I need to build will be inner classes in a non-GUI wrapper, like so:
public class MyWrapper extends MyBaseClass {
...
class MyPanel extends JPanel {
...
}
}
So my question is this: can I construct MyPanel using WindowBuilder? If so, how should I set it up?
If anyone is interested, the wrapper is an abstract base class which the plug-ins I am developing for my app must extend; deployment concerns mean that it's not really practical to put the GUIs in a separate JAR either so I pretty much have to do it this way.
My current workflow, which is awful, is to build the GUI in NetBeans and paste the entire generated class into Eclipse where I connect it up to the methods in my wrapper. I am very hopeful that WindowBuilder will let me work more reliably and efficiently if I can trick it into generating code in MyPanel, not MyWrapper.
Thanks

It isn't clear why the JPanel must be an inner class. In general, that is not a good idea (you will end up with multiple .class files either way). The JPanel should just be its own top-level class and referenced from your wrapper class (all of which can be in the same jar). WindowBuilder can easily be used to create/edit your JPanel subclasses (including ones originally created with NetBeans), but it will only do so for top-level classes. It won't allow you to create/edit an inner class like this (which is entirely intentional).