As programmers, we strive for a high level of software quality. When building cloud computing services, without this kind of structured software development methodology, the chance for error is needlessly increased. We must question how we can best achieve the core principles of Object Oriented Programming (OOP), such as encapsulation, inheritance, data hiding, reusability, and security. There are several ways to program a module/piece of code, but the wiser programmers opt to align code (even the small pieces) in a strong, structured manner by adopting design patterns. These patterns also help to easily maintain the code.

What generally happens in application development (due to strict deadlines, early releases, and other aspects of deliverables) is that programmers sometimes use shortcuts to solve the modules that add complexity, in terms of management, to code base. This complexity leads to problems, so why not to get rid of them from the start? (see: Virtualization in Custom Software Development and Testing) Rather, programmers should create a strong foundation for the project/code that will better the management of the code base, even with cases of ad hoc changes or requirements.

What exactly are design patterns? Design patterns define roles or responsibilities for objects or isolate the responsibilities for them. For example, the MVC design pattern assigns isolated responsibilities to the Model, View, and Controller objects. Let’s now take a look at some specific design patterns and how they work.


The singleton pattern allows a same or single object (Suppose DB engine Object) to float through out the application life cycle.

Singleton for software development


The façade pattern allows an interface to represent a complex sub system. In general terms, instead of exposing a big set of classes and their APIs, a single, unified API does the job.

Facade for software development


The decorator pattern adds behaviors and responsibilities to any object dynamically without modifying its code base. Examples: categories, extensions, delegation. Suppose there is a class database that is used to store and retrieve data, which communicates with a physical database. If more responsibilities or APIs (Behavior) need to be added to that class to manipulate data, it can be achieved through “extensions” by just extending the database class to some other class by making a “category” of it.


The adapter pattern allows two incompatible interfaces or classes to become compatible. Apple implements this pattern though protocols. For example, say you name a protocol as “UITableViewDataSource.” If your Class A is compliant to the protocol, the class has to implement all the methods and functions defined in that protocol. Even if Class A is not compatible with the function of the “UITableViewDataSource,” it executes the function regardless.


The observer pattern is all about communicating between different incompatible objects. Suppose there are 2 classes, A and B. The task for class A is to send a particular message to class B when the X button is pressed. An Observer can be connected to the Object (X button). When the button is pressed, the class A object will send a notification to the class B object that describes the set Observer pattern.


The memento pattern captures and externalizes an object’s internal state. In other words, it saves your stuff somewhere. Later on, this externalized state can be restored without violating encapsulation; that is, private data remains private. Say there is a case to save the last played song and re-play when the app becomes active again. Here is when the Memento pattern can be applied. An Object should hold the last state of the application here including the time, album name, song name, album path in the physical directory.


The command pattern captures an action or function as an object, so the defined command can be executed later. Apple implements the Command pattern through Target-Action and Invocation concepts. The benefit of using this pattern is that it decouples (loosely couples) the sending object from the receiving object, and it can send a request or chain of requests on its own.

Why Design Patterns are Useful

There are several positives to using these patterns for your benefits. Complicated tasks become simplified and easy to use. The most powerful feature is that patterns allow you to design your code as loosely coupled (decoupled). Apart from that, it ensures a level of reusability in your code. For example, another developer involved in your project would be able to understand your code easily and know what each class exactly does in your app.

However, design patterns should not be used in every line of code you write. Keep the patterns in mind, and use them to solve particular problems. Especially, at the early stages of designing an application, it makes the life of a developer much easier, plus the code looks better! Happy Coding!

Everything you need to know about outsourcing technology development
Access a special Introduction Package with everything you want to know about outsourcing your technology development. How should you evaluate a partner? What components of your solution that are suitable to be handed off to a partner? These answers and more below.

Introduction Package

Senior Software Engineer, Zymr, Inc.


Leave a Reply