In the Desktop Swing application, there is the Item class in the Data package, the ItemFrame class (graphically filling and editing the Item class) in the GUI package, and the NetWorker class in the NetDB package for working with DB and network. The names of classes and packages are conditional.

According to the program logic, when creating (and editing) an instance of the Item class, a graphical interface ItemFrame into which data is entered, when you click the Save button, an Item object is created that should be written to the DB and, under certain conditions, methods should be called to transfer it over the network and write to XML.

It turns out that when the button is pressed, the Item constructor from another package is called, and the methods for working with DB and the network from the third one are called. Looks a bit confusing. How, in this case, to properly organize the structure, in which class which methods are best implemented?

The correct decision interests from the point of view of OOP.

    1 answer 1

    You are on the right track. Dividing packages into duties is right. The fact that there will be some place that the code from several packages causes is inevitable.

    Perhaps you should stick to the classic three-layer architecture UI-> BLL-> DAL (arrows indicate the direction of interaction). You already have the first and last layers, it remains to enter a layer of business logic. The UI will pass data to it (or an already filled Item ), BLL will create / take the transferred Item and be generated to NetDB for saving.

    • That is, now the situation is normal, when everything related to the GUI, including interface event handlers, is in one package, everything that is connected to the DB and the network in another, and the business of logic, as such, is not present, there is only one class in BLL? - Tariel
    • one
      @Tariel yes. The separation of the package itself is absolutely correct! Because each package / layer has a strictly defined remit. The fact that you have a small BLL is a temporary situation. The application will expand, BLL (and other layers) will grow. For example, you may need to validate the data entered in the UI. It should be done on the BLL side. - andreycha