For enquiries call:

+1-469-442-0620

For enquiries call:

+1-469-442-0620

All Courses

Bootcamps

Enterprise

Resources

Home
Blog
Programming
Android Development Principles | Guidelines

HomeBlogProgrammingAndroid Development Principles | Guidelines

Android Development Principles | Guidelines

Blog Author

Sabih Javed

Published

05th Sep, 2023

Views

Read TimeRead it in

0 Mins

In this article

Android Development Principles | Guidelines

Getting started with Android development seems to be a big challenge. You’ve to have a deep understanding of android development principles and basic guidelines. Unfortunately, most of the developers don’t get the chance to learn the basics until it’s too late. If you’re just starting out, there are certain principles and guidelines that you’ve to stick to. What are these?

Let’s dive in.

Android development principles can be best explained by the SOLID acronym, as devised by Robert Martin. It refers to:

Single Responsibility
Open-Closed Principle
Liskov Substitution
Interface Segregation
Dependency Inversion

Robert Martin developed these five object-oriented design principles for the sole purpose of helping developers deliver maintainable and extensible systems. These principles not only help in writing a well-structured code but they also make sure that the code can easily be extended later. Take, for example, .NET. In the beginning, .NET was a mess and it were these principles that helped developers make a well formatted code for .NET applications and websites.

So, let’s have a look at these principles individually.

Single Responsibility

Single Responsibility, as its name suggests, means that your classes should have only one responsibility. For example, if you have to perform calculations, mapping, and formatting, make 3 separate classes to handle each responsibly rather than making one class to handle all 3.

But, what exactly do we mean by responsibility? A responsibility can be thought of as a “reason to change”. If you can think of more than one reason to change a class then you are probably breaking the Single Responsibility rule.

The reason behind Single Responsibility is that it makes your class more complex and lead to code duplication issues which almost always ends up with non-updated codes.

Open-Closed Principle

This means that your software entities like classes, functions, modules etc. should be open to extension but not modification.

This is a very basic principle that should be followed no matter what platform you are coding for. This principle requires you to write a class or function or module in a way that it does need to be changed whenever your requirements change.

For example, if you are making a class to calculate the area of a shape like a circle then you shouldn’t change the class every time a new shape comes as an input. Designing a base class and then extending it with the help of inheritance, or any other technique depending on the language you are using, is the way to go.

This way, you won’t be making a change in the class for every new shape.

Liskov Substitution Principle

This is the type of a principle that is very tricky to explain even though almost all of us follow this principle unintentionally.

Liskov Substitution Principle says that:

“Objects should be replaceable with their subtype instances without having the need to alter the program.”

This might be confusing but let me explain it with the help of an example.

Let’s say you made a class that requires a List Object to perform a certain task. Now, what if we send an ArrayList Object to this class instead of a List Object? The class shouldn’t work right?

No, the program will work just fine. The reason is the Liskov Substitution Principle.

The ArrayList Object is a subtype of List class and, since, List class is an abstraction, the ArrayList Object will work without any problem.

In short, you can replace the objects of List with any of its subtype without causing the program to break. So, if you require T and S in a subtype of T, then objects of T should be replaced by the objects of S without changing the properties of the program, especially the correctness property.

Interface Segregation Principle

This is a pretty straight forward principle. The Interface Segregation Principle states that there should be a lot of Client-specific User Interfaces rather than a general purpose User Interface.

Let’s say a user has to enter his email address, fill a survey, and enter his favorite food. In this case, it would be better to make 3 separate User Interface pages instead of a single general purpose page that asks all of these questions.

A general purpose User Interface will make your code complex because of the multiple callbacks as well as make the user confused. Remember, always give users small achievable goals rather than a big time-consuming task.

Dependency Inversion Principle

The Dependency Inversion Principle covers two things:

High-level modules should be independent of the low-level modules. Both should depend on abstractions.
Details should depend on Abstractions instead of Abstractions depending on the Details.

You will be increasing the de-coupling by making your High-level modules independent of the low-level modules. Being a developer, you should know that requirements for an application changes a lot. And, changes are risky.

So, making your modules independent will make them reusable as well as significantly reduce the risks involved in changing the implementations.

In short, you will reduce the risk of changes by depending on the abstractions, for instance, interface rather than implementations.

A few great tips for android developer that helps who wants to become one, you will undoubtedly have noticed that there are literally hundreds of thousands of apps on the Google Play store.

Sabih Javed

Blog Author

Sabih Javed is a digital marketer, blogger, and a tech-geek. He is the founder of Digital Marketer PK where he publishes what he does. He is currently working with CounponBuffer as Marketing Manager.

Share This Article

Ready to Master the Skills that Drive Your Career?

Avail your free 1:1 mentorship session.

Upcoming Programming Batches & Dates

Name	Date	Fee	Know more

Useful Links

Course Advisor