Check put pur solution to reduce writing boilerplate code
The root cause
At Tooploox, we strive to develop high-quality code. We want it to be well-structured, modularised, scalable, testable and, most importantly, to follow SOLID principles. After years of experimenting, we’ve come up with our own variation of Uncle Bob’s Clean Architecture. If you want to learn more about it, please refer to our introductory article. Clean architecture is rather complex, and it relies heavily on abstracting and partitioning the codebase. This leads us, programmers, to create multiple files for every single module we implement. We need to have a dedicated connector, presenter, view, use case and gateway. Even though for each module these layers differ, they share some of the code. Layers throughout the app usually make use of the same imports, conform to the same protocols, keep references to other layers or simply have the same form of the initialiser. This list can be endless, depending on your project.
Presenter
By taking a look at one of our projects, we identified that all of our presenters always keep a strong reference to the connector and a weak one to the view. This is how the shared codebase among our presenters looks like after removing the rest of the code:
Connector
Connectors, in this project, are always subclasses of BaseConnector class, which implements some basic routing.
View
View layer is composed of a View Controller and a View Protocol. The former always conforms to its corresponding protocol and is a subclass of BaseViewController class, which includes some UI common for all of our views.
Relief
When your app grows, you find yourself with tens or hundreds of such modules. Even a simple authorization itself can become a few modules. In some cases, it makes more sense to have them separate for login, signup, authorize with social media, reset password etc. Creating a dozen files with boilerplate code is time-consuming and frustrating, and the more you have to do it, the more frustrating it gets.
This has led us to the invention of a tool – SBG, which would solve our problem. What we wanted to accomplish was to have a single-command tool which, given the module name, would generate all the necessary files in the correct directories and with all boilerplate code already there. Nevertheless, SBG is highly customizable and can do much more than just eliminating boilerplate side-effects arising from any architecture choice. This tool will let you automate any repeatable code pattern in your app. All you have to do is translate your pattern to a Stencil template, define a few project constants and pass module name, and SBG will make sure to generate your files and add them to a correct group and target in your .xcodeproj.
Translating your pattern
Let’s take a look at our sample project again. To generate files, we need a template for each of them and a generator along with the configuration file. To increase reusability, we will define variables both in Stencil templates and in the generator. You can do it by putting curly brackets around the variable name, like `{{module_name}}`. The variable value can be set either in the configuration file or using the command line.
Presenter template
Connector template
View template
Now that we have all the templates, we need to create a generator file, where, for each step, we specify a group and a target of the project, and link templates with names of the files we will generate.
SBG Generator
SBG Configuration file
The last thing we have to do is set values for all our variables in the config file.
How to run it
To run SBG and generate files, type the command below in the terminal:
You can also specify any variable by adding “– parameter_name parameter_value” to the command. This will replace every occurrence of the “parameter_name” within the templates or generator with “parameter_value”. If some value is already assigned to the variable in the config file, it will get replaced by the new value given in the command. For example, we could overwrite the values of our main target and connectors path variables by running:
SBG is an open source tool, so feel free to participate. Both feedback and pull requests are more than welcome.
