-1

I need a little advice with project design. I have taken on a personal project to enhance my knowledge of Java Swing, API integration, JDBC and OOP

I have chosen to do this in Java as I previously did a similar project in HTML and JSP's and learnt a lot.

For those who are interested, here is a breakdown of the App

From the homepage of the App:

An admin can click log in

  • They enter username and PW (database call)
  • Once Logged in they can add, view or delete users (database calls)
  • They can then logout (back to app home screen)

A user can click to log in

  • Once logged in they can view the share price of a stock (API call)
  • They can add a stock to their portfolio (database call)
  • They can remove a stock from their portfolio (database call)
  • They can view their current portfolio (database call)
  • They can then logout (back to app home screen)

As i have never programmed like this in java before, what is the best road to take ?

  1. Should I design all the GUI components first and then build the functionality around this? or have my app working from the console and then create the GUI ?
  2. Should I try implement some sort of framework ? I haven't used Frameworks before so the learning curve i imagine will be steep
  3. Should I implement an architecture type? I know the theory behind MVC as i used in the JSP Restful project. But as this project inst overly complicated, maybe I don't need to.

Appreciate your thoughts and any other design aspects you think I should be thinking about, please let me know.

  • 2
  • Fair enough, my question is a bit broad then - to narrow my question down, is it better practice to create GUI components and then create the functionality or better to have the program working before adding buttons and windows? This will give me a place to start off – Kevin Jun 29 '17 at 11:28
  • If you make a CLI first, then you have written two user interfaces. Why would you do that? – Sebastian Redl Jun 29 '17 at 12:18
  • @SebastianRedl Many solutions have different parts which can use different user interface paradigms / plataforms. Many big software solutions are not "one app". But this being a hobby/self-learning project I get your point. – Tulains Córdova Jun 29 '17 at 19:53
  • What would be the main reason/purpose of the workout? Learning the Java's GUI Api? Learning how to build apps (domain + UI) with Swing as GUI? Sharping your programming methodologies at work? – Laiv Jul 1 '17 at 9:38
0

is it better practice to create GUI components and then create the functionality or better to have the program working before adding buttons and windows?

In this case it's just you developing, but if there were multiple people this could easily happen simultaneously. It's not right or wrong to do one before the other.


Re: Specific questions

Should I design all the GUI components first and then build the functionality around this? or have my app working from the console and then create the GUI ?

If by "working from the console" you mean writing a CLI, then no I don't think that's a good approach in this case. IMO that would be some unnecessary work and writing of code that you don't ultimately need.

That aside, there is no correct answer to the question of writing UI first or not. If you follow a good design pattern you could easily write a UI that doesn't do anything yet (or mock the database interaction). On the same token you could write all of your data access code first without a UI and - with some unit tests - verify that the database code works before writing the UI.

Should I try implement some sort of framework ? I haven't used Frameworks before so the learning curve i imagine will be steep

Maybe? It depends on what you're trying to accomplish. If you want to learn a specific framework, then by all means use it. If you do decide to use a specific framework, be sure that it suits your needs and that you're not using it simply because someone said you should.

Should I implement an architecture type? I know the theory behind MVC as i used in the JSP Restful project. But as this project inst overly complicated, maybe I don't need to.

MVC (or MVP, etc.) is certainly a good pattern that you could follow. You say the project isn't overly complicated, but you may be surprised how much code you end up writing and how the complexity grows quickly! Following a good pattern can help you here to keep things modular, readable, maintainable and easy to spot bugs.


Re: "thoughts and any other design aspects"

Swing

If you're looking to learn a UI framework that would be useful going forward, then I would stay away from Swing and use JavaFX instead.

Other

I would recommend taking this project one piece at a time: create a non-function UI and write the data access code separately before wiring everything together. This will help you focus on one aspect and ensure that you're making good design decisions (and perhaps following a pattern like MVC, MVP, etc) on that layer. Naturally you may need to make changes later, but not nearly as many as if you try to do it all at once - that gets messy in a hurry!

When starting each stage, consider creating your interfaces first. For example when writing the data access code, ask yourself "What interactions do I need, and what do I expect in return?" Then create some interfaces with methods like addUser(), deleteUser(), addStock(), removeStock(), etc. depending on what you need. Then you can create specific implementations of your interface depending on the technology used (eg. a SQL database, MySQL, etc. etc.). The same is true for the UI (implementations for the specific framework used) and making the API calls to retrieve stock prices (implementation for the specific API used). This provides flexibility for swapping out a UI framework, database technology, or stock API.

Lastly, consider posting to Code Review once you have something that is working! It sounds like your goal here is to learn, and having other people critique your code is a great way to learn!

0

This is the classic model-view-controller problem (see this Wikipedia article). Personally the way I work is to do small pieces of the model first before the view. Then once I have a working set of data structures, create a small view for those. Then I add on to the model, and add on to the view. I repeat this pattern until everything is done. I think one of the most important things I have learned in my projects (mostly Java) is that views are very fluid and often need to change. Therefore, it's better to define an interface for the view which the view can access so that you can "sub in" different views if you need to in the future. For that reason, following the MVC pattern usually leads to more malleable code because you can change out the views (and the controller) as needed.

0

If you have a very solid spec that isn't going to change much, such as a (theoretical) "waterfall" projct, then creating the GUI late makes sense.

In an "agile" project, or one where you suspect the spec is flaky and your stakeholders will change things, write a mock GUI early and often. This "GUI" could be as simple as sketches on index cards. Dont worry about getting every pixel right, and work on basic functionality.

0

I prefer an in-depth development having made a total traject, a working application, and then adding features. Without some measures this could easily be the recept for a disaster. So I do the following:

  • First look at one or more demo samples and make a playground application, without much structure! This allows you to see the flow, and the mechanisms involved. Swing uses listeners, partly on models, to determine changes, JavaFX uses a Property, which wraps a value, and has its own change listener. JafaFX is more slick than swing. It takes a bit more of learning, and I would not start with FXML on top.
  • Then start with a clean prototype of just a piece of functionality.

This should be a fast first milestone. If still no version control system, start with one: git or mercurial are easy. Integrate in your IDE SonarLint or SpotBugs.

  • Develop test driven; with unit tests to develop a data model and quasi-algebraic operations on the model. This is a fast way to build scenarios, test data, and conceive what you want to achieve: all features of the application.
  • Database design, Entities should now be a no-brainer. The data model should already be there. Note that for JPA (Java Persistence API), like eclipseLink, the database design (with annotations) is integrated from start. And for Test Driven Development one could start with an embedded H2 database.
  • Incremental GUI design now functionality can be added to the GUI. It still sometimes pays to start with a prototype is a separate application, should something complex like a table require much experimenting.

Should I design all the GUI components first and then build the functionality around this? or have my app working from the console and then create the GUI?

You can make prototypes; a swing JTable needs a TableModel, a JavaFX might benefit from an ObservableList, and integrating a more abstract data model might come easier. However I prefer the classical optimum: algorithms + data structures, in test driven development. That motivates a good concept which is worth gold. Nevertheless GUI design is work too: thinking on an Excel import of a list, one might also think of importing a list copied onto the clipboard. Intelligence, list different ways (components) of selecting being synchronized.

Should I try implement some sort of framework? I haven't used Frameworks before so the learning curve i imagine will be steep

Using a framework could turn into a back alley and hide too much. But it can also be a next level of abstraction, opening a new world. The Java Persistence API, say in the newer eclipseLink, might be such an O/R mapping, with many aspects. Creating a framework will in general not be worth open-sourcing it. But it might be a form of modularisation: separating specific usage for a business goal, from pure GUI code. Like creating a general purpose auto-completion text combobox filled with business domain data.

Should I implement an architecture type? I know the theory behind MVC as I used in the JSP Restful project. But as this project inst overly complicated, maybe I don't need to.

Separating data model, controller and view is beneficial. But to display a list, the code should never be bureaucratically blown up: ust a controller class (servlet) loading locally the list (data model) from the database, forwarding it to a view (JSP) presenting it nicely. Here the view does not need to know about its controller as in full MVC. And the list does not need to be a Model class.

It is worth to mention another aspect: documentation. Using package-info.java to document how the classes fit together (short text). Human readable styled text documentation for the business logic, use cases and so on. Even single-person project benefit when a project is put aside for longer period. Do not hesitate to write why you took short-cuts, left out some functionality and so on.

The most important: persist in delivering the project. A project consumes and produces energy: to find an icon set costs time, but having nice icons motivates. Hence my first milestone to have a working initial application fast, and to add features incrementally.

protected by gnat Oct 20 '17 at 17:25

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.