Interview Queations 4 Desing Patterns

1) How can we achieve singleton pattern in iOS?

 

The Singleton design pattern ensures a class only has one instance, and provides a global point of access to it. The class keeps track of its sole instance and ensures that no other instance can be created. Singleton classes are appropriate for situations where it makes sense for a single object to provide access to a global resource.

Several Cocoa framework classes are singletons. They include NSFileManager, NSWorkspace, NSApplication, and, in UIKit, UIApplication. A process is limited to one instance of these classes. When a client asks the class for an instance, it gets a shared instance, which is lazily created upon the first request.

2) What is delegate pattern in iOS?

 

Delegation is a mechanism by which a host object embeds a weak reference (weak in the sense that it’s a simple pointer reference, unretained) to another object—its delegate—and periodically sends messages to the delegate when it requires its input for a task. The host object is generally an “off-the-shelf” framework object (such as an NSWindow or NSXMLParser object) that is seeking to accomplish something, but can only do so in a generic fashion. The delegate, which is almost always an instance of a custom class, acts in coordination with the host object, supplying program-specific behavior at certain points in the task (see Figure). Thus delegation makes it possible to modify or extend the behavior of another object without the need for subclassing.

1. MVC – Introduction

As implied with the name, the MVC software design pattern refers to three separate roles: the model, the view and the controller.
The idea is that the objects in your application will take on these roles and work together to create and manage the user interface. Not all objects will assume one of these 3 roles; For example you might have a class that contains a bunch of helper methods however, the model, view and controller roles are the central actors to making your app function.
The Model
The model represents the data in your application. It’s responsible for sorting, validating and organizing your data.
The View
The view is the user interface or what the user sees and interacts with.
You can create views programmatically through code using Apple classes such as UIView or you can create a XIB file to represent the view and visually layout your elements through Interface Builder.
The Controller
The controller manages the communication between the view and the model. It takes the data from the model and communicates it to the view for display.
In the same vein, the controller also takes the changed data (due to user interaction or something else) and communicates it back to the model.
The Model And View Never Talk To Each Other
They shouldn’t even know about each other in the ideal case.
The beauty of this modular architecture is that the separation of roles allow us to make modifications easily with less bugs.
For example, if in the future, you need to make a change to the way the data is fetched or organized, all you need to do is switch out the model. As long as you keep the interface of the model the same (the header file), then the views and controllers will be none the wiser.

Here’s a diagram illustrating what we’ve talked about: