Design Patterns Print E-mail
Written by Mark Tebbs   
Tuesday, 19 May 2009

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:

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

    Description

    Example
    Result
    Client Interface = new Adaptor(Old Interface)Enumeration enumeration = hashtable.elements();
    Iterator itr = new EnumerationAdaptor(enumeration);

    Calls made on the Iterator object will be translated to the Enumeration object.

     

  • Decorator
  • A design pattern used to dynamically add functionality to a class without sub-classing
     DescriptionExample
    Result
    Add more functionality with each instantiation. No sub-classing required.on object.InputStream fileInputStream = new FileInputStream("test.txt");
    InputStream buffStream = new BufferedInputStream(fileInputStream);
    InputStream in = new LowerCaseInputStream(buffStream);

    We now have an InputStream that lowercases characters in the stream.

 NOTE: Debugging is more difficult with this design pattern.

  • Façade
  • A higher-level interface that hides system complexity from users, but still allows access to the complex functionality
     Description Example Result
    Client Interface = new Facade(Object, Object, …)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)
     
    The façade for the automobile will provide a simple interface to the client while hiding all the complexity of the automobile.
  • Factory method
  • A design pattern that defines an interface for creating an object
     Description Example Result
    Client Interface = Create object.Pizza pizza = new CheesePizza (); // New Object
    Pizza pizza = StaticPizzaStore. createCheezePizza(); // Static factory
    Pizza pizza = CheesePizza.getInstance(); // Static factory

    Use Spring:
    <bean id="newYorkCheesePizza" class="factoryexample4.pizza.NewYorkCheesePizza" lazy-init="true"/>
        <bean id="newYorkStylePizzaStore" class="factoryexample4.store.NewYorkStylePizzaStore" scope="prototype">
                          <property name="newYorkCheesePizza" ref="newYorkCheesePizza"/>
                </bean>
     
    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.

  • Observer
  • A design pattern that defines a one-to-many dependency between objects to notify dependents and update automatically when an object changes state.
     Description Example Result
    Observer object is notified of changes of an object being observed.

    Observable object contains:

    • Register Observer object (addListener(listener))
    • Un-Register Observer object (removeListener(listener))
    • Notify Observer objects (notifyListeners())
    • Update object (update(source,state))
    When observable object changes state, it notifies registered observer objects.

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.

Add Comment

 

You have no rights to post comments

LDSTech Missionaries

Learn how to become a full time or part time LDSTech Missionary.

LDSTech Chapters

Sign up for an LDSTech Chapter in your area.

Meetinghouse Technology

Support for Meetinghouse Technology is available on the MHTech site.

LDS Connected

Subscribe

RSS RSS
Email Email
Twitter Twitter