Support free tutorials









vogella training Training Books



Design Patterns in Java - Tutorial

Lars Vogel

Version 0.4

30.12.20010

Revision History
Revision 0.1 02.07.2007 Lars
Vogel
created
Revision 0.4 02.09.2007 - 30.12.20010 Lars
Vogel
bug fixes and updates

Design Pattern

Design Patterns are best practices how to solve common know problems. This article will give an overview of best practices in object-orientated programming and has pointers to some design-pattern tutorials.


Table of Contents

1. Design pattern in software development
2. Object Orientated Programming
2.1. Encapsulation
2.2. Abstraction
2.3. Polymorphisms
2.4. Inheritance
2.5. Delegation
2.6. Composition
2.7. Aggregation
2.8. Design by contract
2.9. Cohesion
2.10. The Principle of Least Knowledge
2.11. The Open Closed Principle
3. Pattern
4. Support this website
4.1. Thank you
4.2. Questions and Discussion
5. Links and Literature

1. Design pattern in software development

Design patterns are proven solutions approaches to specific problems. A design pattern is not a framework and is not directly deployed via code.

Design Pattern have two main usages:

  • Common language for developers: They provide developers a common language for certain problems. For example if a developer tells another developer that he is using a Singleton, the another developer (should) know exactly what this means.

  • Capture good practices: Design patterns capture solutions which have been successfully applied to problems. By learning these patterns and the related problem, an unexperienced developer learns a lot about software design.

Design pattern are based on the base principles of object orientated design.

  • Program to an interface not an implementation

  • Favor object composition over inheritance

Design Patterns can be divided into:

  • Creational Patterns

  • Structural Patterns

  • Behavioral Patterns

Note

The terminology Design Pattern in software development is primary based on the book Design Patterns - Elements of Reusable Object-Oriented Software from Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides.

2. Object Orientated Programming

OO programming suggests that you use the following principles during the design of a software. The following are not "Design Principles" but a repetition of a good OO design.

2.1. Encapsulation

In general a general manipulation of an object's variables by other objects or classes is discouraged to ensure data encapsulation. A class should provide methods through which other objects could access variables. Java deletes objects which are not longer used (garbage collection).

2.2. Abstraction

Java support the abstraction of data definition and concrete usage of this definition.

The concept is divided from the concrete which means you first define a class containing the variables and the behavior (methods) and afterwards you create the real objects which then all behave like the class defined it.

A class is the definition of the behavior and data. A class can not be directly be used.

A object in an instance of this class and is the real object which can be worked with.

2.3. Polymorphisms

The ability of object variables to contain objects of different classes. If class X1 is a subclass of class X then a method which is defined with a parameter for an object X can also get called which an object X1.

If you define a supertype for a group of classes any subclass of that supertype can be substituted where the supertype is expected.

If you use an interface as a polymorphic type any object which implements this interface can be used as arguments.

2.4. Inheritance

Inheritance allows that classes can be based on each other. If a class A inherits another class B this is called "class A extends class B".

For example you can define a base class which provides certain logging functionality and this class is extended by another class which adds email notification to the functionality.

2.5. Delegation

Delegation is then you hand over the responsibility for a particular task to another class or method.

If you need to use functionality in another class but you do not want to change that functionality then use delegation instead of inheritance.

2.6. Composition

When you refer to a whole family of behavior then you use composition. Here you program against an interface and then any class which implements this interface can be used to be defined. In composition the composition class is still defined in the calling class.

When you use composition, the composing object owns the behaviors is uses and they stop existing as soon as the composing object does.

2.7. Aggregation

Aggregation allows you to use behavior from another class without limiting the lifetime of those behaviors.

Aggregation is when one class is used as part of another class but still exists outside of that class.

2.8. Design by contract

Programming by contract assumes both sides in a transaction understand what actions generate what behavior and will abide by that contact.

Methods usually return null or unchecked exceptions when errors occurs in programming by contract environment.

If you believe that a method should not get called in a certain way just throw an unchecked runtime exception. This can be really powerful. Instead of checking in your calling code for exceptions you just throw an exception in the called code. Therefore you can easier identify the place in the coding their an error occurs. This follows the "crash-early" principle, which tells that if an error occurs in your software you should crash immediately and not later in the program because then it is hard to find the error.

2.9. Cohesion

A system should have a high cohesion.

Cohesion is a measure of how strongly-related and focused the responsibilities of a single class are. In object-oriented programming, it is beneficial to assign responsibilities to classes in a way that keeps cohesion high.

Code readability and the likelihood of reuse is increased, while complexity is kept manageable, in a highly-cohesive system.

Therefore you should avoid classes which have several responsibilities, e.g. a Logger class should only be responsible for logging.

2.10. The Principle of Least Knowledge

Talk only to your immediate friends.

Also known as Law of Demeter.

2.11. The Open Closed Principle

Software entities like classes, modules and functions should be open for extension but closed for modifications.

This principles encourages developers to write code that can be easily extended with only minimal or no changes to existing code.

An example for a good application of this principles would be that a certain class calls internally an abstract class to conducted a certain behavior. At runtime this class is provided with an concrete implementation of this abstract class. This allows the developer later to implement another concrete calls of this abstract class without changing the code of the class which uses this abstract class.

Another excellent example is the Eclipse Extension Point method. Eclipse Plugins or Eclipse based application can define extension points where other plugs-ins can later add functionality.

3. Pattern

Please see the following description for details on the design pattern.

Singleton

Observer

Facade

Adapter

4. Support this website

This tutorial is Open Content under the CC BY-NC-SA 3.0 DE license. Source code in this tutorial is distributed under the Eclipse Public License. See the vogella License page for details on the terms of reuse.

Writing and updating these tutorials is a lot of work. If this free community service was helpful, you can support the cause by giving a tip as well as reporting typos and factual errors.

4.1. Thank you

Please consider a contribution if this article helped you. It will help to maintain our content and our Open Source activities.

4.2. Questions and Discussion

If you find errors in this tutorial, please notify me (see the top of the page). Please note that due to the high volume of feedback I receive, I cannot answer questions to your implementation. Ensure you have read the vogella FAQ as I don't respond to questions already answered there.

5. Links and Literature

http://en.wikipedia.org/wiki/Design_Patterns Wikipedia Entry about the GOF Design Pattern book.