Architecture for my Java application [closed]

Question

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

I try to create small Java tools to help me at my work every now and then. Usually these do not have to be pretty and I find myself coding a single, sometimes massive, Java class. However, now my plan is to create a tool for myself that would parse certain files for me and create desired output as a result. I'd like this tool to have a GUI and I'd like to use Swing for that. However, I cannot seem to get my head around the concept of how I should devise my application - classes, packages and such.

I plan on having a simple Swing GUI with a file chooser, the application will crunch the input (this logic is fairly clear to me), and output the result summary into the GUI and ask the user to specify a directory path where to save the output file(s). How should I separate my application logic into separate classes? I would be fairly happy if someone could point be to a great article or something of the sort; what does the application main class usually include, how should the GUI be separated from the application logic, and so on.

I do not want to cram all my code into a single class anymore, since it does not make my code scale nor easy to maintain.

Answer 1

When it comes to design, it is usually a good idea to have an idea of design patterns. This will help you better visualize the best way to structure your application. It is worth noting though, that you should choose the design patterns depending on what you need to do, and not try to force your design to conform to a specific design pattern.

At the very least in your case, you will need to have at least 2 classes, one being the Swing front end, and another being the processing/parsing mechanism. The UI is usually the main class and it takes care of starting/loading other modules.

Exposing a series of methods (within the UI class) which facilitate the printing of data to the user usually also helps, since the logic part of the program (in your case, the second class) would not need to be concerned with how should its output be rendered. So for instance, you could have a method in your UI class called showResultToUser(String result). This will in turn use the appropriate mechanisms to display it in a meaning full way to the user.

If you will be parsing multiple file structures, in my opinion you could create a separate class for each file type, this would help you keep your code segregated, thus making it easier to change one piece without breaking the rest.

Also, segregating UI with logic can make it easier to have the logic execute in separate threads. It is never recommended to have heavy operations, such as file processing, database operations etc on the UI thread (Event Dispatcher Thread). Launching the parsing mechanism in a separate thread (and maybe pass a reference to the UI class as well, so that the logic can do something particular when it is finished) would allow your application to remain responsive.