views:

149

answers:

8

What are the general guidelines and best practices to keep in mind while designing Java application [Simple console apps to J2EE apps]?.

Hi

I recently completed Java programming tutorial from Sun and practised core java (I have previous programming experience). Now I understand the basics of Inheritance, Abstraction , Polymorphism,Encapsulation

Now i am writing Java code without much difficulty, but am not sure of application design. This is my main problem: "DESIGNING" the application. Say if i have given a task to create an application in Java, What should I start up with? How to think about? Any formal/informal guidelines I should follow while developing class hierarchies? I am really confused (abstract class or interface or sub class..?). Should I start by model everything, before writing code?

It would be very useful for people like me to have a SET OF GENERAL GUIDELINES/BEST PRACTICES, which we can follow while start developing a new java application.

Please provide me some guidelines/thoughts/books/resources/tools I should read or Use

Thanks in advance Scott

+2  A: 

It is difficult to give really general advice as there are so many different Java apps on different domains. However, one absolutely recommended book is Domain Driven Design by Eric Evans. See also Wikipedia for a short intro on it.

General advice:

  • don't try to design everything up front - do a reasonably good design which enables you to start coding, then refactor as your understanding of the problem domain and the implementation deepens
  • try to divide difficult problems into smaller parts/steps/modules which you can tackle one by one
  • try to think in terms of objects with well defined responsibilities, which (more or less) model the problem domain and cooperate to solve a problem / handle a task
  • becoming good at design requires practice, first and foremost; don't be afraid to make mistakes. However, when you do, analyze them and learn from them as much as you can
  • learn design patterns, but don't be overzealous - use them only when they really solve a problem and make your code cleaner
Péter Török
yes, a very good book
Jean-Philippe Caruana
Very useful hints peter. Will keep in mind. I am in the process of learning design patterns.
Scott
A: 

Start by looking up UML Class diagrams that will get the ball rolling in the right direction, then take a look at Gang of Four design patterns. That is an excellent first step.

http://en.wikipedia.org/wiki/Class_diagram

http://en.wikipedia.org/wiki/Design_Patterns

Lastly, I would pour over good open source code like the Spring Framework

http://www.springsource.org/

Ayubinator
And yes you should definetly model everything, but be willing to go back and change the model if it doesn't work. The key is flexibility...
Ayubinator
+1  A: 

Welcome to stack overflow. If you are good with Java, read Head First Design Patterns. and Head First Object-Oriented analysis and design - er, may be in reverse order :)

ring bearer
I won't throw myself into Design Pattern if I were a beginner.
Jean-Philippe Caruana
Thanks. am already started with headfirst java..
Scott
+1  A: 

I'd recommend emergent design with TDD.

I think there is nothing specific to Java design : if you already know about Object Design, you're ready to go !

Jean-Philippe Caruana
I disagree. The classes you would design for a Java app are almost certainly different from the classes you would design for the same app in C++ or C# -- not to mention languages like SmallTalk or OCaml.
Gabe
+1  A: 

There are various paradigms (very often 3 letters acronyms) :

  • DDD : Domain Driven Design
  • SDD : Serviice Driven Design
  • MDA : Model Driven Architecture (code and architecture is extracted from the UML model)
  • TDD : Test Driven Development (validation tests are implemented before the application)

With theses key-words, you'll find a lot of informations on the web.

In J2EE, I would say that the SDD is the most used (it is now very "normalized", even if I'm not sure it is the best solution) : service (software "intelligence") > domain (bean objects used for persistance) > DAO (persistance).

Now DDD is becoming more and more used : the conception is refocused on domain objects, which are taking the "software intelligence" layer.

Benoit Courtine
Thanks, You introduced some new concepts to me..
Scott
TDD is not a design approach per se (although it can be used to _test_ the usability of your API, and as such it is very useful). MDA was very much hyped in the 90s, then it faded away, for a good reason: UML is a very good tool for _communicating_ your design, but not good for generating source code from it.
Péter Török
A: 

Do not start coding immediately without having any design. But this does not mean that you should design all before coding. Because from my previous experiences, I could not have any design which does not need corrections. Especially if you are new in a programming language your design will change according to the features of the language you are using and the libraries available. My advice is to have a general design which is based on the most important aspects of object oriented design such as inheritance, polymorphism, encapsulation etc. Starting from this general design and the needs you encounter while programming, revise your design accordingly.

As much as you get experienced in the language, your first general design will fit in a much more efficient way to your program.

Although most of the people say that one object oriented design should be able to be written in any object oriented language, it is not that easy to have a very good generic design like that. To be more realistic, disregarding the language that is used for implementing a particular design is not a good way as far as I am concerned.

Mustafa Zengin
Thanks Mustafa. What am doing now is writing small applications with an intial design that does the core functionality, then refactoring the code(rediesgning) to follow oop.
Scott
A: 

Well odds are what you'll be doing has already been done before - at least something similar. Luckily, there's lots of open-source stuff nowadays. So if you really have no idea, one thing you can do is download several open-source applications that do the same thing and study them. It should give you a good start.

JRL
A: 

In my opinion it all boils down to meeting the below

  1. easy to understand
  2. easy to maintain and evolve
  3. multiple developers able to contribute to the project (mostly in parallel)

To achieve the above there are certain guidelines and principles that are suggested by experts based on experience which are

  1. Follow layered architecture (http://en.wikipedia.org/wiki/Multitier_architecture)
  2. follow the SOLID principles within h and across layers. All the design patterns are one way or the other help achieve these principles only (http://www.lostechies.com/blogs/chad_myers/archive/2008/03/07/pablo-s-topic-of-the-month-march-solid-principles.aspx). SRP: Single Responsibility Principle, OCP: Open Closed Principle, LSP: Liskov Substitution Principle, ISP: Interface Segregation Principle, DIP: Dependency Inversion Principle
  3. DRY and KISS principles

These guidelines and principles are independent of any programming paradigm or language. However, OOP languages help implement these easier.

Pangea