[1] Singleton
When a class is restricted to just one instantiation, that one object is called a singleton. A singleton class returns the same instance no matter how many times an application requests it.
Example :
+ (instancetype)sharedManager {
static DocumentManager * sharedDocumentManager = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedDocumentManager = [[DocumentManager alloc] init];
NSLog(@"Singleton memory address: %@", sharedDocumentManager);
});
return sharedDocumentManager;
}
[2] Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Creates a base class with abstract methods defining methods for the objects that should be created. Each factory class which derives the base class can create their own implementation of each object type.
Ex : Button factory produces windows button or OS X button based on type.
[3] Factory method
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
[4] Category
Categories allows you to extend the behaviour of existing classes by adding new class or instance methods. Unlike subclass we cannot add instance variable.
At runtime there is no difference b/w a method added by a category and one that is implemented by the original class. Declared in separate .h and .m files
Ex: ClassName + CategoryName.h
Syntax :
@interface ClassName (CategoryName)
@end
[5] Class Extension
Similar to category, but it can be only be added to a class for which you have source code at compile time. Also called Anonymous categories or Category with no name. Useful for hide private information.
Syntax :
@interface ClassName ()
@end
[6] Protocols
Protocol is set of methods and properties that encapsulates a unit of functionality. The protocol does not actually contain any of its implementation for these things; it early defines the required elements. Any class that declares itself to conform to this protocol must implement the methods and properties dictated in the protocol.
Multiple inheritance can be achieved as class can adopt more than one protocol.
@protocol ProtocolName
//List of methods and properties
@end
//Confirming to protocol
@interface myClass:NSObject <protocolName>
//….
@end
[7] Formal Protocol
Formal Protocols allow us to define the interface for a set of methods, but implementation is not done. Formal Protocols are useful when you are using DistributedObjects, because they allow you to define a protocol for communication between objects, so that the DO system doesn't have to constantly check whether or not a certain method is implemented by the distant object.
[8] Informal Protocol
Informal protocols are typically declared as categories of the NSObject class, because that broadly associates the method names with any class that inherits from NSObject. Because all classes inherit from the root class, the methods aren’t restricted to any part of the inheritance hierarchy.
[9] Delegation
A delegate is an object that acts on behalf of, or in coordination with, another object when that object encounters an event in a program.
Message passing between 2 objects. (one to one, if we need one-to-many, then use observer pattern). No subclassing involved. Delegation work hand in hand with protocols because it allows a class to specify a delegate property which confirm to some protocol. Then second class which actually confirms to that protocol can assigned to that property.
Now first class can be communicate with the second class thought the delegate property using the methods and property as defined by the protocol.
[10] Data source
Data source is like delegate, except that its method supply data for another objects to display. The difference is in the relationship with the delegating object. Instead of being delegated control of the user interface, a data source is delegated control of data. The delegating object, typically a view object such as a table view, holds a reference to its data source and occasionally asks it for the data it should display. The data source pattern fits nicely in the MVC pattern.
[11] MVC
Model View Controller design pattern is a popular way to make logical divisions among class responsibilities.
Each object oriented programming environment/language has a slightly different definition/convention of MVC.
The main advantage of adopting a design pattern like MVC is that it allows the code in each unit to be decoupled from the others, making it more robust and immune to changes in other code.
[12] KVO (Key Value Observer)
Key value observing (KVO) is a pattern in which one object can observe the value of another object’s properties to find out about changes. Where the previous two patterns (delegation and notifications) are more suited to a controller communicating with arbitrary objects, KVO is more suited for objects of any type listening for changes of another arbitrary object (not necessarily, and most often not a controller). It is a way in which we can keep our objects in sync with one another; a way in which we can make one object react when another object’s state changes. It is only used for properties and cannot be used to respond to methods or other actions.
[13] KVC (Key value coding)
Key-value coding is a mechanism for accessing an object’s properties indirectly, using strings to identify properties, rather than through invocation of an accessor method or accessing them directly through instance variables. E.g. NSDictionary and NSMutableDictionary
"Keys" are just strings, and "values" can be any type of object.
[14] Key value path
Cocoa makes a distinction between "keys" and "key paths". A "key" allows you to get a value on an object. A "key path" allows you to chain multiple keys together, separated by dots.
For example :
[p valueForKeyPath:@"spouse.name"];
… is exactly the same as this…
[[p valueForKey:@"spouse"] valueForKey:@“name"];