
A design pattern can be defined as a general repeatable solution to a commonly occurring problem in software design. It won’t be the exact solution whereas it would just give a template to solve a solution.
Why design patterns?
•They give the developer a selection of tried and tested solutions to work with
•They are language neutral and so can be applied to any language that supports object-orientation
•They aid communication by the very fact that they are well documented and can be researched if that is not the case.
•They have a proven track record as they are already widely used and thus reduce the technical risk to the project
•They are highly flexible and can be used in practically any type of application or domain
Types of Design Patterns:
Creational Patterns
These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using the new operator. This gives the program more flexibility in deciding which objects need to be created for a given use case.
Structural Patterns
These design patterns concern class and object composition. The concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
Behavioural Patterns
These design patterns are specifically concerned with communication between objects.
Two main reasons for many codes to be in such bad shape is,
1. Continuous changes in UI.
2. Lack of an architecture that supported the flexibility that we needed.
Architectural patterns are used to overcome these problems.
Architectural Patterns in Android:
The three most commonly used Architectural Patterns in Android are
- MVC(Model View Control)
- MVP(Model View Presenter)
- MVVM(Model View View Model)
Model:
The Model represents a set of classes that describe the business logic i.e. business model as well as data access operations i.e. data model. It also defines business rules for data means how the data can be changed and manipulated.
View:
The View represents the UI components like CSS, jQuery, HTML etc. It is only responsible for displaying the data that is received from the controller as the result. This also transforms the model(s) into UI.
MVC(Model View Control):
The Controller is responsible to process incoming requests. It receives input from users via the View, then processes the user’s data with the help of Model and passing the results back to the View. Typically, it acts as the coordinator between the View and the Model. The Architecture of MVC is given below.
MVP(Model View Presenter):
The Presenter is responsible for handling all UI events on behalf of the view. This receive input from users via the View, then process the user’s data with the help of Model and passing the results back to the View. Unlike view and controller, view and presenter are completely decoupled from each other’s and communicate to each others by an interface. The architecture of MVP is shown below.
MVVM(Model View View Model):
The View Model is responsible for exposing methods, commands, and other properties that help to maintain the state of the view, manipulate the model as the result of actions on the view, and trigger events in the view itself.
Simply any change that takes place within the model will be automatically updated in the view itself. The Architecture of MVVM is shown below.
Thus we have seen about design patterns in details and in specific saw about the design patterns used in Android. Next week we will come up with another interesting topic to explore.
–
What!!!??? I think you are confused, you are talking about architectural patterns (tfrancocas, MVVM, MVP, Clean Architecture, VIPER, etc.), not design patterns(Builder, Repository, Singleton, Adapter, Factory, Facade, etc.)
Hi Franco,
Thank you for your comment. We have informed the same to the author and will correct the same as soon as possible.
Why did you removed my last comment? You are wrong about what you are talking about, architectural patterns(MVC, MVP, MVVM, Cleal Architecture, VIPER, etc) are not the same than design patterns(Singleton, Repository, Builder, Facade, Abstract Factory, Proxy, Decorator, etc.)
Hi Franco,
We haven’t removed your comment. Just it took some for approval. We have conveyed your points to the author. Will get back to you and make necessary changes. Thanks again.
My apologies for the second comment, you can delete it if you want.
Regards.