Hey Guys! We all heard the term design patterns, and we know that this is very important for our project, yet when it comes to writing code we don’t pay attention too much for reusing codes.Why we care if there is more than one instance of the same class? Or copy paste the same methods in some classes over and over when code and memory is cheap. However, there are some cases  in which it makes sense to have exactly one instance of a class. For example, there is only one instance for your application and one main screen for every device. So you only want one instance for each. Actually Apple uses this approach a lot. So we will examine their patterns and see how to use them to make our codes more readable and increase its reusability. For example, NSFileManager.defaultManager(),UIApplication.SharedApplication(), UIScreen.MainScreen() are the example of the singleton pattern.

If you copy/paste some of your methods in classes over and over OR if you are rechanging the same function in other classes when you are adding a new functionality to the same method, I guess it is time to use Design patterns.

• They are reusable in multiple projects.

• Design patterns don’t guarantee an absolute solution to a problem. They provide clarity to the system architecture and the possibility of building a better system.

• They also help you create loosely coupled code so that you can change or replace components in your code without too much of hassle. 🙂

  Don’t worry we are already using IOS design patterns thanks to the Cocoa! So lets dive into this patterns with simple examples!

  Most Common Design Pattern – MVC

  I am not going to write what MVC is, instead I will show with a simple example. Here is the Model – View – Controller, the king of the patterns 🙂

  The clean separation of the code based on the role.

  • A Model , which represents the underlying, logical structure of data in a software application and the high-level class associated with it. This object model does not contain any information about the user interface.(Basically,The object that holds the data and defines how to manipulate it. It has nothing to do with the UI)

  • A View , which is a collection of classes representing the elements in the user interface (all of the things the user can see and respond to on the screen, such as buttons, display boxes, and so forth)- basically all the UI – derived objects.

  • A Controller , which represents the classes connecting the model and the view, and is used to communicate between classes in the model and view.(The mediator that coordinates all the work between model and the view. It accesses the data from model and displays it with the views – listens the events and manipulates the data if necessary.)

  • A good implementation of this design should mean each object falls into one of these groups.

  

  This is how it works basically.
  Soo lets start our very simple project. First, Open Xcode then select the “Create a new Xcode Project”, Then choose “Page-Based Application”, give the name you want to your project in the “Product”and select the lang Swift and click Ok.Here is your project with 4 swift classes.

  1. AppDelegate.swift
  2. RootViewController.swift
  3. DataViewController.swift
  4. ModelController.swift

  AppDelegate might look like full of mostly empty functions but it is the main file of our swift project. There is a part written “@UIApplicationMain”, this means Xcode will assume this file as the main file.
  

  ModelViewController  is the place where the data is shown, variable pagedata holds the date to show in init().(Model)
  

  let dateFormatter = NSDateFormatter() 
  pageData = dateFormatter.monthSymbols
  

  
  DataViewController is the place where UIView is shown, displaying datalabel.(View)
  

  RootViewController updates the data from ModelViewController in the DataViewController. DataViewController can then notify the controller of user actions and the controller will either update the model if necessary.(Controller)