IOS Design Pattern

 Design Pattern is an important Aspect of IOS Development, for writing an efficient and user friendly code we must follow an effective design within our program.

It not only increase code reusability but also enhance its efficiency.

In Short Lets start with what is Design Pattern ? 

Design patterns are reusable solutions to common problems in software design. 

They’re templates designed to help you write code that’s easy to understand and reuse. They also help you create loosely coupled code so that you can change or replace components in your code without too much of a hassle.

The most common Cocoa design patterns:

1. Creational: Singleton and Abstract Factory.

2. Structural: MVC, Decorator, Adapter, Facade and Composite.

3. Behavioral: Observer, Memento, Chain of Responsibility and Command.

Lets have a sort introduction about some major Design that we need to adopt while developing Application.

# Model View Controller (MVC):

 Model View Controller (MVC) is one of the building blocks of Cocoa and is undoubtedly the most-used design pattern of all. It classifies objects according to their general role in your application and encourages clean separation of code based on role.

The three roles are:

Model: The object that holds your application data and defines how to manipulate it. For example, in your application the Model is your Album class.

View: The objects that are in charge of the visual representation of the Model and the controls the user can interact with; basically, all the UIViews and their subclasses. In your application the View is represented by your AlbumView class.

Controller: The controller is the mediator that coordinates all the work. It accesses the data from the model and displays it with the views, listens to events and manipulates the data as necessary.

 Can you guess which class is your controller? 

That’s right: ViewController.

# The Singleton Pattern

The Singleton design pattern ensures that only one instance exists for a given class and that there’s a global access point to that instance. It usually uses lazy loading to create the single instance when it’s needed the first time.

Apple uses this approach a lot.

 For example: 

[NSUserDefaults standardUserDefaults]

[UIApplication sharedApplication]

[UIScreen mainScreen] 

[NSFileManager defaultManager]

all return a Singleton object.

# The Decorator Design Pattern

The Decorator pattern dynamically adds behaviors and responsibilities to an object without modifying its code. It’s an alternative to subclassing where you modify a class’ behavior by wrapping it with another object.

In Objective-C there are two very common implementations of this pattern: 

Category and Delegation.

Category

Category is an extremely powerful mechanism that allows you to add methods to existing classes without subclassing. The new methods are added at compile time and can be executed like normal methods of the extended class. It’s slightly different from the classic definition of a decorator, because a Category doesn’t hold an instance of the class it extends.

Delegation

The other Decorator design pattern, Delegation, is a mechanism in which one object acts on behalf of, or in coordination with, another object. For example, when you use a UITableView, one of the methods you must implement is tableView:numberOfRowsInSection:.

You can’t expect the UITableView to know how many rows you want to have in each section, as this is application-specific. Therefore, the task of calculating the amount of rows in each section is passed on to the UITableView delegate. This allows the UITableView class to be independent of the data it displays.

# The Observer Pattern

In the Observer pattern, one object notifies other objects of any state changes. The objects involved don’t need to know about one another – thus encouraging a decoupled design. This pattern’s most often used to notify interested objects when a property has changed.

The usual implementation requires that an observer registers interest in the state of another object. When the state changes, all the observing objects are notified of the change. Apple’s Push Notification service is a global example of this.

If you want to stick to the MVC concept (hint: you do), you need to allow Model objects to communicate with View objects, but without direct references between them. And that’s where the Observer pattern comes in.

Cocoa implements the observer pattern in two familiar ways:

Notifications and Key-Value Observing (KVO).

Notification :

Notifications are based on a subscribe-and-publish model that allows an object (the publisher) to send messages to other objects (subscribers/listeners). The publisher never needs to know anything about the subscribers.

Notifications are heavily used by Apple. 

For example, when the keyboard is shown/hidden the system sends a UIKeyboardWillShowNotification/UIKeyboardWillHideNotification, respectively.

 When your app goes to the background, the system sends a UIApplicationDidEnterBackgroundNotificationnotification.

Key-Value Observing (KVO)

In KVO, an object can ask to be notified of any changes to a specific property; either its own or that of another object.

Encryption and Decryption: 

Encryption is the process of translating plain text data (plaintext) into something that appears to be random and meaningless (ciphertext).

Decryption is the process of converting ciphertext back to plaintext. 
To encrypt more than a small amount of data, symmetric encryption is used.
A symmetric key is used during both the encryption and decryption processes. To decrypt a particular piece of ciphertext, the key that was used to encrypt the data must be used.

The goal of every encryption algorithm is to make it as difficult as possible to decrypt the generated ciphertext without using the key. If a really good encryption algorithm is used, there is no technique significantly better than methodically trying every possible key. For such an algorithm, the longer the key, the more difficult it is to decrypt a piece of ciphertext without possessing the key. 
OS X and iOS provide a number of encryption technologies. Of these, three APIs are available on both iOS and OS X: 
Keychain Services API—provides secure storage for passwords, keys, and so on
Cryptographic Message Syntax—provides (nonstreaming) symmetric and asymmetric encryption and 
decryption
Certificate, Key, and Trust Services—provides cryptographic support services and trust validation 

What is dispatch_once ? 

The behavior of dispatch_once is in the name. It does something once and only once. 
It takes two parameters. The first is a predicate that tracks the "once". The second is a block to execute on the first call. Calls look like this: 
static dispatch_once_t predicate; dispatch_once(&predicate, ^{ 
// some one-time task 
});
It's a great API for lazily initializing shared state, whether it's a global dictionary, a singleton instance, a cache, or anything else that needs a bit of setup the first time through.