top of page
  • Writer's pictureLuda Fux

The Benefits of Modularization

When embarking on a greenfield project, the initial development phase often feels like a breeze. Features are fresh, and there’s no need to grapple with someone else's code. Everything flows smoothly, and the codebase evolves organically. However, as the project matures and new developers join, the code can become tangled, making it harder to understand, modify, or extend.


Enforcing Separation of Concerns

Enforcing separation of concerns by splitting the code into modules ensures that each module has a clear responsibility, making the overall structure more manageable and paving the way for future scalability. When an application is modularized, you must explicitly import other modules to use their classes and functions. This necessity compels developers to be mindful about what should be exposed publicly and what should remain private, fostering a more disciplined and efficient development process.


Mindful Development Practices

While setting up modules and defining public access modifiers may seem to slow down development in the short term, it's important to remember the long-term benefits. This discipline pays off as the application grows, preventing the code from becoming overly entangled and making future development faster and more efficient. Each module only builds its dependencies, not the entire codebase, reducing build times. This benefit is further enhanced with the introduction of explicitly built modules, which allow for parallel builds, giving developers more confidence in the scalability and efficiency of their work.


Initial Time Investment

Modularization does take some extra time at the beginning. However, this upfront investment saves much time in the long run, as the code will be more manageable. Retrofitting modularization into an existing codebase is very challenging, so it’s much better to implement it from the start.


Approaches to Modularization

There are a few approaches when approaching modularization:


Here is a template project that utilized the third approach. The package file describes all the modules which can be imported and used in other parts of the code.


Managing Access Levels with Packages

  • Accessing classes, properties, or methods in another package requires them to be explicitly public.

  • By default, these elements are private, ensuring encapsulation.

  • To access classes, properties, or methods within the same package but across different targets, such as for testing purposes, use the internal access level.


Conclusion

Modularization might introduce some upfront complexity but fosters a cleaner, more maintainable codebase in the long run. The benefits are Separation of Concerns, Quicker Builds, and Quicker Development in the Long Term.


These benefits become increasingly apparent as projects scale, leading to more efficient and sustainable software development practices.


Couple of Visual Resources

Package.swift file describing different submodules and targets:

Corresponding targets:



223 views

Recent Posts

See All

Navigating the Sea of iOS Knowledge 🌊

For the past few months, I've been diligently keeping a list of all the things I want to learn and implement in iOS development. Every day, I learn something new and put it into practice. Yet, the mor

Consolidated ViewState

Managing multiple states in SwiftUI views can be complex and error-prone. This post addresses the issue by introducing a consolidated generic ViewState enum, simplifying state management, reducing bug

Comentarios


bottom of page