Design patterns
- Reusable solutions to common problems in software design
- Templates to help write code that’s easy to understand and reuse
- Facilitate loosely coupled code so that components in your code can be changed/replaced with less hassle
Model-View-Controller design pattern
- The most-used design pattern
- Classifies objects according to their general role
- Encourages clean separation based on role
- A STRUCTURAL design pattern
Model
In MVC, the object that holds your application data and defines how to manipulate it. (e.g.. AlbumView.swift).
View
In MVC, the objects that are in charge of the visual representation of the Model and the controls the user can interact with; basically, all the UIView-derived objects. E.g. the AlbumView class.
Controller
In MVC, 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. E.g. the ViewController.
MVC diagram
See evernote
Singleton pattern
- A design pattern that ensures that:
(a) only one instance exists for a given class and,
(b) there’s a global access point to that instance. - Usually uses lazy loading to create the single instance when first needed
- A CREATIONAL design pattern
Facade design pattern
- Provides a single interface to a complex subsystem
- Decouples the code that uses the system from the interface and implementation of classes you are hiding
- Useful if the classes under the facade are likely to change
- A STRUCTURAL design pattern
Decorator design pattern
- Dynamically adds behaviors and responsibilities to an object without modifying its code (an alternative to subclassing)
- Two common implementations of this pattern: EXTENSIONS and DELEGATION.
- A STRUCTURAL design pattern
Extensions
- Powerful mechanism that allows you to add new functionality to existing CLASSES, STRUCTURES and ENUMS without having to subclass
- Can extend and enhance code you don’t have access to
- Common example of the Decorator design pattern
Delegation
- A mechanism in which one object acts on behalf of – or in coordination with – another object.
- Common example of the Decorator design pattern
Adapter design pattern
- Allows classes with incompatible interfaces to work together.
- Wraps itself around an object and exposes a standard interface to interact with that object.
- A STRUCTURAL design pattern
Observer design pattern
- One object notifies another of any state changes
- Objects don’t need to know about one another - which encourages a decoupled design
- Used most often to notify an interested object when a property has changed
- A BEHAVIORAL design pattern
Notifications
- An implementation of the Observer design pattern
- 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.
- Used heavily by Apple.
Key-Value Observing (KVO)
- An implementation of the Observer design pattern
* An object can ask to be notified of any changes to a specific property, ether its own or that of another object.
Memento Pattern
- Captures and externalizes an objects internal state.
- That is, it saves stuff, somewhere.
- Later, this externalized state can be restored without violating encapsulation; that is, private data remains private.
- A BEHAVIORAL design pattern.
Archiving
- A specialized implementation of the Memento pattern.
- Converts an object into a stream that can be saved and later restored without exposing private properties to external classes.
