Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
1  
This is subjective. I like the mix of from top/from down approach. I call my chaotic approach 'agile'. I do start with a quick GUI mock-up just to see what it will feel like, and then move on to a mix of db / plumming. I do not like to finish any one part completely in isolation. I like to play with it, see what kind of noises it makes when it runs and how to make it better, what to add and what to take out. I start with GUI first because I believe that usability is ultimately most important to the user, not the extra 20 ms. Just look at the popularity of the iPhone. –  Job Nov 14 '11 at 0:24
2  
@Job This kind of subjective question should theoretically be the good kind. Ideally we'd see a few well-reasoned and well-motivated answers explained in sufficient detail for the OP to choose from. It looks like your comment would make a good basis for one of those answers. :) –  Anna Lear Nov 14 '11 at 0:31
add comment

7 Answers

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).

share|improve this answer
add comment

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.

share|improve this answer
    
Can you explain me briefly what is domain logic? –  Иван Бишевац Nov 14 '11 at 17:55
2  
Domain logic is synonymous with business logic. It contains all the information on how different pieces of data interact with each other and how to maintain its integrity. Think about foreign key constraints in a database; domain logic will, in part, ensure that no data being inserted into the database breaks this constraint. Additionally, it contains any algorithms you use to solve a problem. For example, Google maps performs calculations on the fastest path between two addresses, this would be implemented in the domain logic. –  Jonathan Nov 14 '11 at 23:20
add comment

In theory, there are at least five possible approaches.

Top-Down:

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.

Bottom-Up:

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.

Logic first:

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.

Horizontal expansion:

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
2  
I suppose you are assuming a rather large (multiple man-months) system here. –  Job Nov 14 '11 at 2:13
    
Any project I'm not planning to throw away within the month, so yeah. –  Jonn Nov 14 '11 at 3:02
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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