Copyright © 2007 Lars Vogel
|Revision 0.4||02.09.2007 - 30.12.20010||Lars
|bug fixes and updates|
Table of Contents
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:
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
Talk only to your immediate friends.
Also known as Law of Demeter.
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.
Please see the following description for details on the design pattern.
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.
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.