If you are a business looking to build a mobile app, there are multiple aspects to think about before contracting a web developer. For instance, you might consider the costs and the operating system, and whether you’d like a hybrid or native app. Will it be a standard app or a completely customized solution? All of these considerations are important, but first understanding the basics of mobile app architecture can help you make the right decisions about your future app.
Building a high-quality mobile app requires an understanding of “Clean Architecture.” Not so long ago, a programmer and writer, Robert C. Martin, also known as Uncle Bob, revealed the concept of Clean Architecture to the general public. This concept implies that all parts or levels of a software app should be independent enough that when change occurs in one compartment, other parts remain unaffected. In more abstract terms, the concept suggests that inner layers (core layers) cannot be dependent on outer layers. This idea relies heavily on the Dependency Rule, also coined by Uncle Bob in the 1990s.
Uncle Bob’s vision of software levels functioning as independent and easily substitutable units correlates with the Agile approach, which breaks up the process and the software itself into increments to speed up development and avoid error.
Tips for Writing Clean Code in a Nutshell
Let’s go over the “Clean Architecture Model” in detail, starting with the most inner layer:
- Entities
- Use Cases
- Controllers, Presenters, Gateways
- Infrastructure
Entities and Use Cases – are the core and most unchangeable elements of the system. In an object-oriented language, entities are classes with objects that contain states and methods. For example:
Class-animal
Object-dolphin
State-awake/asleep
Method-eyes closed/eyes open
Use cases are multiple logical statements that describe various behaviors of the object. For example, if inactive for > 30 sec., then eyes are closed.
When you start thinking of building a new app for your business, considering and discussing entities and use cases becomes mega important. That is the exact point of your software building journey where pure theoretical and super abstract concepts become a reality. As our customer, you should decide up front what kind of app you are going to build. Entities and use cases are the number one priority you should focus on because they will outline the dynamics and logic of your future app. With the Agile philosophy, you can tell us the details via user stories. We worship user stories because they play a crucial role in the software development lifecycle!
Controllers and Presenters are involved in information processing via MVC and MVP models. Each time a user interacts with the UI, the controller responds to the input and interprets it for use cases and entities, passing the request on to the Model. Then the query proceeds from Model to View via Presenter. The user taps on the dolphin icon and it wakes up, eyes open! That is a great example of Clean Architecture practice. The presenter protects the Model and the core logic by having pure code that is specific to the request and free of framework-based code.
Gateways are IO adapters between objects and external data sources such as databases.
Infrastructure encompasses all external entities such as frameworks, platforms, databases, libraries, devices, and UIs. This layer is prone to change and requires separation from use cases and entities. Communication between layers takes place via interfaces and gateways.
Coming back to the main point of Clean Architecture, the inner layer does not know about the outer layer. The entities do not depend on use cases or any other layer. But use cases rely on entities. At the same time, use cases do not care about the infrastructure layer. But the infrastructure layer falls back on information from the inner core to execute a user-query and render the results on the screen.
There are several aspects or rules worthy of mentioning when discussing Clean Architecture – SOLID, KISS, DRY, and YAGNI.
S: Single Responsibility Principle: Every class should have one task or single responsibility
O: Open Closed Principle: We can add additional functionalities to class but can’t modify it
L: Liskov Substitution Principle: The logic of superclasses should work fine for subclasses
I: Interface Segregation Principle: Don’t incorporate methods that classes don’t use
D: Dependency Inversion Principle: The higher class must not rely on the lower. You can achieve this by placing an interface or abstract class in-between.
KISS – keep it simple stupid! Simplicity is the number one requisite for quality programming. A simple and straightforward code defines a good program. Simple code often involves breaking methods and functions into increments. Nobody appreciates lengthy and complicated solutions. As a project progresses and more functionalities appear along the way, disorganized code can become detrimental to the whole project. Adhering to SOLID principals is key to keeping your code simple.
As Uncle Bob says:
“So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.”
― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship.
In other words, save time by writing simple and perfect code from the very beginning.
DRY – don’t repeat yourself! This principle suggests writing the logic for a specific class just once, without repetitions. But if the same scenario is necessary for other sections of the project, it is possible to reuse the method of the logic without copying or rewriting it. Repetitions make things messy, especially as the project gets bigger. Besides, every change in existing code will require corrections in all copies of the logic. If things get out of hand, the program may become full of bugs, inconsistencies, and malfunctions.
YAGNI – you aren’t going to need it! This rule is about using software that only relates to a specific project task, even if you are tempted to add extra features to extend the functionality and scalability of the program in the future. Steering clear of adding extras is essential for good planning and cost saving. The final product should contain only the capabilities the client initially requested, and nothing beyond that. The program should fulfill its precise purpose.
Applying Clean Architecture to your custom-build mobile app
If you are a start-up or business looking to create a quality custom native Android or iOS mobile app, learn the basics of Clean Architecture. Clean Code practice will grant you a concise, durable, cost-effective, and easily-testable product. Besides, Clean Architecture lets you separate core logic from infrastructure. This type of mechanism makes your app independent and unique.
Clean Architecture predisposes practical and concrete solutions to fit your custom needs, without using anything superfluous. As per Uncle Bob:
“Architecting for the enterprise, when all you really need is a cute little desktop tool, is a recipe for failure.”
― Robert C. Martin, Clean Architecture: A Craftsman’s Guide to Software Structure and Design
Today most progressive software development firms adhere to clean architecture principles to provide exceptional services to their clients. Make the right choices for your company by going “clean,” and good luck with your future projects!