I want to write my first Java program, for example Phonebook, and I wonder what to do first. My question is should I write GUI classes first or util classes first? I am database developer and want to know best practice in building program.
If you are a database developer I think you should start with a data model and create a good abstraction layer so that it is easy to define your user interface (be it GUI or not).
Personally, I would analyze the user concerns and go from there. Ideally, the aspect of the application that requires the most amount of work should start first.
In this scenario, I'd focus on UI mocks as a primary focus. The customer has expressed concern over supporting a diverse end user group, especially those with visual impediments, and distributing the system across cultural lines. Thus, while having a functional and stable system will be critical, the importance of having an interface that will allow users to easily accomplish work takes precedent.
This scenario would have me focusing on the domain logic. The customer has requested a system with complex business interactions. It will store large amounts of complex data structures. Thus initial work discovering and implementing the business logic with data source storage will lead to a successful project.
If the system is a personal project, then focus on what you want to learn from the project. If I am trying out a new technology, I try to focus on a small spike with it and isolate the technology itself so I can better grasp how it works. However a personal project that goes through all the stages will have the benefit of better preparing you for "real" projects. In that case, I'd outline some major goals and use those as a stepping stone. If this phone book app is a personal project of yours, I would suggest working through the UI first. As a database developer, I am assuming that you know how to connect databases to domain logic and roughly how to write domain logic, but have not explored UI technologies as much; thus working on the UI should benefit your learning more than starting from the data source or domain logic.
In theory, there are at least five possible approaches.
Start with UI mock-shots or a paper prototype. Turn them into real dialogs, and work your way from the button handlers and other controls down through the logic and to the database.
Start with the data structures (probably the database schema). Then add logic (modelling real-world processes); finally, your UI is just an interface to trigger the logic and display the results.
Start with the program logic, implementing data access and a rudimentary UI as needed. Then formalize and harden the data structures, and finally flesh out the UI properly.
Meet in the middle:
Start with database schema and UI, and simultaneously work towards the point where they meet. With this approach, the logic comes last.
Start by identifying the absolute minimum amount of functionality that would do something interesting, and implement the whole stack (data structures, logic, and UI) for this part. It could be just a basic CRUD cycle with a simple edit dialog for just one entity. Then start adding more features, implementing the whole stack for each feature (hence 'horizontal').
Each of these has pros and cons.
Top-down gives you something visible early in the process, and allows you to check your functional design with stakeholders - mock-shots often tell users more about a design than flowcharts or walls of text.
Bottom-up gives you a chance to design a rock-solid database schema before you commit to anything; since a database schema is notoriously hard to modify once released, you want to get this part right - the impact of modifying a UI is much smaller and produces fewer and less severe bugs.
Logic-first means you can test the logic before spending serious time on the database and the presentation, which is especially interesting if your logic is going to be really complex.
Meet-in-the-middle combines the advantages of bottom-up and top-down, but you'll have to jump back and forth between two tasks, and you risk ending up with logic that is more complex than necessary because your two ends don't meet naturally.
Horizontal expansion goes well with an iterative workflow, and it has the added advantage that, if you prioritize well, you will have a working application at any given time, so if you don't make a deadline, you will have a version that has fewer features, but is still fully functional, as opposed to a version that has a complete database, but no UI at all.
So which one you choose depends on your personal style, and on the circumstances.
Start with the part of the project you find most interesting. If you start with the part you don't like you might quit before you make progress. Where you start is mostly a matter of preference so you might as well choose what you most want to work on.
Start with the domain or what you call 'util classes'. Test it independently of your UI implementation. That way you get a better understanding of how your application behaves (or should behave), how the logic plays out regardless of which UI framework, MVC or whatnot, tools, styles you're planning to use in the end.
Binding yourself to a specific UI implementation is usually a bad idea. I'm not saying that you shouldn't consider it up front. I'm saying that your application shouldn't be dependent on it. The UI tends to change A LOT over the course of a project and if your domain is tied to it then you'll be changing your domain a lot as well.
Almost everyone will have a different method for developing that suits their style. For example, one person may find that its easier to design their GUI if they have defined the underlying architecture and data storage. Another person may find however that playing around with the GUI and getting an initial draft may help them better organize their storage system and code their program in a more organized manner. The task before you will be to find out which method (or perhaps some hybrid of the two) works best for you. For me, I prefer to do an initial mockup of what I think the GUI will look like, then begin working on the nuts and bolts of the application. Once I've done that I typically come back and make changes to the GUI as needed. My recommendation to you is to pay careful attention as you work on small projects and get a feel for the approach that helps you most.
This is a fairly straightforward project where I'd say it's not that important. On many projects though it's not going to be immediately clear exactly how you want the GUI to look and operate, and once you make it someone may ask you to change it. It's good to make quick mockups of the GUI so you or whoever is in charge can come to a concrete decision on what it should look like and then this will give help you see some of the correletive pieces of data you'll need to track that you might not have noticed had you started with the data design.
More importantly, you do NOT want your data design to drive your user interface. Relatively speaking, I believe fixing poor GUI implementations is far easier than fixing poor data implementations. So I definitely vote for starting with the GUI.
And I'm more of a database guy myself, just fyi.