A number of mobile apps development courses stress upon the need for creating future-driven adaptable codes. This means that every developer should write a code that is designed to cater to the needs of the present but is adaptable to accommodate any future requirements as well. It helps your brand to move with time and keep up with the latest trends.
SOLID is an acronym that combines five principles to ensure that you design for the future. The primary object-oriented design principles of SOLID include:
- Single Responsibility Principle – for high-level architecture and about actors.
- Open-Closed Principle – class designing while considering future feature extension.
- Liskov Substitution Principle – talks about inheritance and subtyping.
- Interface Segregation Principle – about business logic as a response to client communication.
- Dependency Inversion Principle – helps in regarding and respecting all other principles.
Let us try and understand these principles one-by-one along with useful examples:
Single Responsibility Principle (SRP)
As the name suggests, the Single Responsibility Principle indicates that every class should have one and only one responsibility.
For example, consider a class ‘A’ that can carry out the following processes:
- Open a connection to the database
- Fetch information from the database
- Write the data content on an external file
As may be seen from above, ‘A’ is taking on a number of operations. Thus, in the event that there is a request for a new database or adoption of an ORM to manage queries on that database or changing the output structure – any of these will greatly modify the class.
Therefore, according to SRP, there should be 3 separate classes to handle all the three operations.
Open-Closed Principle (OCP)
According to this principle, any software entity, whether class, module, function, etc. should be in open state for extension but should be closed for modification. In simpler words, developers should be able to make modifications to the functionality of any code without modifying the source code. Rather, they should write a new code that acts as an extension to the already existing code.
So, for example, if a developer, A, creates a class AA and the developer, B, wishes to add functionality to AA. In this case, instead of modifying AA, B should create a class BB that will act as an extension of AA.
Liskov Substitution Principle (LSP)
As per the Liskov Substitution Principle, the child class may act as a substitution to the parent class without causing any damage to the Android application. Thus, from the client’s point of view, the functionality of an application should not break even if the subclass overrides the methods of a parent class.
In the Android settings, the custom RecyclerView adapter class should be customized in such a manner that it still operates RecyclerView without causing the breakdown of an application. Thus, if you write a code that leads to the misbehaviour of RecyclerView, then you would be violating the Liskov Substitution Principle.
Interface Segregation Principle (ISP)
The Interface Segregation Principle suggests that it is better to implement multiple interfaces that are specific to the client’s requirement rather than developing a general interface. It also recommends the splitting up of a fat interface into a smaller, multi-layered interface. Through this principle, a client will only know about the interface that is required by them. While the above principles are about classes, the ISP speaks about the interface.
Example: If a client wants two different behaviours, say one for click and one for a long press, then you should design and implement two different interfaces dedicated for both actions – click and long press.
Dependency Inversion Principle (DIP)
The final SOLID principle recommends that classes, whether high-level or low-level modules, should be dependent on abstractions. However, abstractions should not be dependent on details, whereas the details should depend on the abstractions. DIP suggests that an object interface must be present to facilitate communication between the concrete classes.
For example, there are two classes, A and B, then the implementation of A must be hidden from the implementation of B and vice versa. Therefore, if either of the class changes, the other need not be bothered about the changes.
Thus, we can see that the SOLID principle helps with OOP in the Android environment. A number of android development certification courses cover SOLID to help their students write high quality code. Once you have written an Android development code using SOLID, it will be easy to maintain, simple to extend, and will help you deliver a robust code.
Your words are your own, so be nice and helpful if you can. Please, only use your REAL NAME, not your business name or keywords. Using business name or keywords instead of your real name will lead to the comment being deleted. Anonymous commenting is not allowed either. Limit the amount of links submitted in your comment. We accept clean XHTML in comments, but don't overdo it please. You can wrap code in [lang-name][/lang-name] tags.