Top IOS Interview Questions and Answers (July 2019) Part I

Previous: Top IOS Interview Questions and Answers (May 2019) Part I

1. What is key difference between Facade design pattern and Singleton?

Facade (simplifies the interface) and Singleton (ensures fixed number, usually 1, of instances for a given object in a library) are two independent design patterns.
A Facade may provide an interface to a set of classes or even an entire library and may or may not make sense for it to be Singleton, depending on the scenario.

Should every Facade be implemented as Singleton? No. It is usually implemented because easier to call, but it gives several disadvantages:

Code coupling
Not-concurrent safe by default
Not Testable

As you can see from the simplified diagram below the facade pattern is one way to achieve this, it provides a unified class which reduces communication between the complex subsystem and its clients. Clients do not have to be aware of the actual implementation of the subsystem and are provided with a simpler interface to this subsystem.

2. If we make multiple Facade class for a big project isn’t it consume more memory of our mobile app? or While using multiple facade class how much of memory it can consume or how much of memory will be needed.

Yes, It will increase memory in runtime but based on the lifetime of object , it will clear it out. The lifetime of a dynamic object begins when memory is allocated for the object (e.g., by a call to init or constructor) and ends when memory is deallocated (when life time of object ends). Dynamic objects are stored in “the heap”.

You’re confusing between two different things: the amount of memory that a class takes (meta-data, or "the blueprint" of the instances) and the amount of memory that an instance takes (data/object).

You can use profilers in order to see how much memory instances.

3. If client interacts with subsystems directly what is the purpose of making new facade layer, what benefit we can get? Pros and Cons of facade pattern?

Clients that access a complex subsystem directly refer to (depend on) many different objects having different interfaces (tight coupling), which makes the clients hard to implement, change, test, and reuse.

Use the facade pattern when:

you want to provide a simple interface to a complex subsystem. The application of design patterns often results in a lot of small classes which makes subsystems more flexible and customizable. A facade can provide a default view for clients which don’t need to customize.
you want to reduce coupling between clients-subsystems or subsystems-subsystems.
you want to layer your subsystems. Use a facade to define an entry point to each subsystem level and make them communicate only through their facades, this can simplify the dependencies between them.

The Facade Pattern has several advantages, summarized in the following points:

The code is more easier to use, understand and test since the facade simplify the interface.
Clean code because the client/context does not use a complex interface and the system is more flexible and reusable.

Drawbacks/Consequences:

One of the drawback is that the subsystem methods are connected to the Façade layer. If the structure of the subsystem changes then it will require subsequent change to the Façade layer and client methods.

4. Where facade layer is use in MVVM model?

The MVVM (Model-View-ViewModel ) Design Pattern requires that you create a facade layer between the Model and the View called the ViewModel.

The ViewModel is supposed to supplement the functionality provided by the Model, and coerce it into a form the View can more readily consume. The result being; the View code can be pretty thin and concerned only with view based activities, while the Model can remain uncompromising by the demands placed on it by a View meaning it can better represent the data/concepts its supposed model.

5. If facade layer increases loose coupling then how subsystems or classes interact with each other if they have dependency for each other ?

Facade promotes weak coupling between the subsystem and its clients. Often the components in a subsystem are strongly coupled.

Facade

knows which subsystem classes are responsible for a request.
delegates client requests to appropriate subsystem objects.

Subsystem classes

implement subsystem functionality.
handle work assigned by the Facade object.
have no knowledge of the facade; that is, they keep no references to it.

Reducing client-subsystem coupling. The coupling between clients and the subsystem can be reduced even further by making Facade an abstract class with concrete subclasses for different implementations of a subsystem. Then clients can communicate with the subsystem through the interface of the abstract Facade class. This abstract coupling keeps clients from knowing which implementation of a subsystem is used.

An alternative to subclassing is to configure a Facade object with different subsystem objects. To customize the facade, simply replace one or more of its subsystem objects.

6. Isn’t it bad experience that if there is a change in subsystems or classes it will effect facade class and client also?

Facade, in general, is about reducing the complexity of interfacing with a subsystem,Even if subsystem or classes change, it affect only facade class implementation but the interface will remain the same.
Assume we build one framework which uses facade and provide interface to consume in application. Now even the subsystem or classes changes or the facade class implementation updated but it doesn't require to change the application code which consumes the API provided by the facade interface.

Take an example, if the day comes when you want to replace your backend service, you won’t have to change the code that uses your API, just the code inside your Facade. Interface or API remains the same.

7. Isn’t it bad to create another layer for facade class which will consume memory of app?

No, client/context does not use a complex interface and the system is more flexible and reusable. It promotes weak coupling between the subsystem and its clients.

8. If i have a project carrying thousands of classes would it be complex to make multiple facade classes and identify functionality?

Consider designing small frameworks which can work independently consist of large number of classes and which uses facade to expose the interface to client. Based on the designing of these component, complexity will varies.

Conclusion

Facade pattern can avoid complexity in your projects, when there are several packages communicating with each other, or a client that requires the use of several classes the facade pattern is perfectly adapted.