Design Patterns

Discuss the feature articles on the LDS Tech Home Page.
User avatar
Posts: 490
Joined: Wed Jul 18, 2007 3:38 pm
Location: Salt Lake City, Utah

Design Patterns

Postby McDanielCA » Tue May 19, 2009 1:38 pm

Design Patterns was originally posted on the main page of LDSTech. It was written by Mark Tebbs.


Software has been written and rewritten to solve the same problems, in a number of programming languages. In an effort to reprocess solutions to commonly occurring problems, design patterns were created. Design patterns provide a way to reuse experience rather than creating new code. Design patterns are simple ways to use proven experience to create higher quality software, regardless of the programming language.

Design patterns fall into four categories: creational, structural, behavioral, and concurrency. Five examples of design patterns include:

A design pattern that allows one system to adapt to another system that is not compatible without changing the interface of either system

<table border="1"><tbody><tr><td valign="top">Description
</td></tr><tr valign="top"><td>Client Interface = new Adaptor(Old Interface)</td><td>Enumeration enumeration = hashtable.elements();
Iterator itr = new EnumerationAdaptor(enumeration);

</td><td>Calls made on the Iterator object will be translated to the Enumeration object.


A design pattern used to dynamically add functionality to a class without sub-classing

<table border="1"><tbody><tr><td>Description</td><td>Example
</td><td>Result</td></tr><tr valign="top"><td>Add more functionality with each instantiation. No sub-classing required.on object.</td><td>InputStream fileInputStream = new FileInputStream("test.txt");
InputStream buffStream = new BufferedInputStream(fileInputStream);
InputStream in = new LowerCaseInputStream(buffStream);

</td><td>We now have an InputStream that lowercases characters in the stream.</td></tr></tbody></table>
NOTE: Debugging is more difficult with this design pattern.

A higher-level interface that hides system complexity from users, but still allows access to the complex functionality

<table border="1"><tbody><tr><td> Description</td><td> Example</td><td> Result</td></tr><tr><td valign="top"> Client Interface = new Facade(Object, Object, …)</td><td valign="top">Brake brake = new Brake();
Dashboard dashboard = new Dashboard();
Engine engine = new Engine();
Transmission transmission = new Transmission()

AutomobileFacade façade = new AutomobileFacade(Brake brake, Dashboard dashboard, Engine engine, Transmission transmission)
</td><td valign="top">The façade for the automobile will provide a simple interface to the client while hiding all the com</td></tr></tbody></table>

A design pattern that defines an interface for creating an object

<table border="1"><tbody><tr><td> Description</td><td> Example</td><td> Result</td></tr><tr valign="top"><td>Client Interface = Create object.</td><td>Pizza pizza = new CheesePizza (); // New Object
Pizza pizza = StaticPizzaStore. createCheezePizza(); // Static factory
Pizza pizza = CheesePizza.getInstance(); // Static factory

Use Spring:
<bean id="newYorkCheesePizza" class="" lazy-init="true">
<bean id="newYorkStylePizzaStore" class="" scope="prototype">

</bean></td><td>Object creation is encapsulated.
NOTE: This code tends to changed because of the new kinds of objects that are to be created or not created.

A design pattern that defines a one-to-many dependency between objects to notify dependents and update automatically when an object changes state.

<table border="1"><tbody><tr><td> Description</td><td> Example</td><td> Result</td></tr><tr valign="top"><td valign="top">Observer object is notified of changes of an object being observed.
</td><td valign="top">Observable object contains:

  • Register Observer object (addListener(listener))
  • Un-Register Observer object (removeListener(listener))
  • Notify Observer objects (notifyListeners())
  • Update object (update(source,state))
</td><td>When observable object changes state, it notifies registered observer objects. </td></tr></tbody></table>
There are many design patterns beyond those described in this article that are very helpful. Design patterns also follow basic design principles to ensure the software is easy to create, maintain, and test. Here are a few principles to consider when designing your own software:

  • Classes should be open for extension but closed for modification
  • Use the Principle of Least Knowledge to minimize the number of other classes that a class interacts with
  • Software should handle changes well
  • Encapsulate object creation
  • Loosely couple classes (do not make them dependent on each other)
  • Prefer composition over inheritance
  • Depend on abstractions rather than concrete classes
The goal should be to design high-quality software that lends itself to change. Regardless of the programming language, applying design patterns to the software creation process that include lessons learned can greatly increase the quality of the software.

Mark Tebbs is a senior software engineer for the Church.

Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest