Version 1.5 is the most substantial new version of our Solr extension for Magento’s product search. Since we have already described the new features, it’s now time to take a look at the changes under the hood.

Refactoring: Intentions

It was our plan to offer an extension for Magento 2 next to the existing one for Magento 1 that triggered the now completed great refactoring. Because of the major difference between the two Magento versions a conversion is not easily done, so in any case you need to create a new extension.
We did not want to start from scratch, but reuse relevant parts of the current Magento 1 extension. Another important factor was our desire to not have to maintain two completely separate modules, for example when a new Solr version needs to be supported.

Framework Independent Code

In order to achieve these aims, the biggest possible share of source code of IntegerNet_Solr needs to be shared between the different module versions. Accordingly, the code must work independent of the framework (Magento 1 and Magento 2 respectively) and only be called by the framework specific part, but it must not depend on it.

Dependency Injection

The Dependency Injection Principle states just the same: code does not depend on any other (in this case framework specific) code, instead it only receives the data and objects it needs. The modules for Magento 1 and Magento 2 can inject the matching data – what matters is that the code sticks to the interfaces introduced by the module in question. The reason is that Magento 1 and Magento 2 use objects, for example product objects, which are incompatible with one another. The framework specific part of the modules now takes care of transforming them into so called Bridge class objects so that they may be used by the framework independent part. The same principle applies to product attributes, product filters, the configuration, etc.
Wherever the module interacts directly with Magento, the related code has to be part of the extension’s framework specific part.

Automated Tests

Another advantage of this refactoring: the created framework independent code is much easier to test automatically due to the reduction of dependencies – that’s something we have taken advantage of. So for great parts of the code we have added unit tests as well as integration tests based on PHPUnit. As a result, possible bugs that might have happened due to a functionality modification are a lot easer to spot, which has a direct impact on the modules’ quality.

Code Quality

Even though IntegerNet_Solr already had a good code quality, this refactoring was able to raise the level even further. Smaller classes and methods improve the code’s readability, and principles such as the Single Responsibility make it easier to extend. At the same time, we implemented modern software design patterns like factories, value objects, facades and bridges – you can read more about that in our blog series “Magento 1 and Magento 2: Shared Code for Extensions”.

Summary

For a long-living extension, used in many different setups, such as IntegerNet_Solr, it’s necessary to have a healthy high quality code base. Thanks to the substantial refactoring we performed our module meets this claim, so now we can focus on using this basis to proceed with the implementation for Magento 2.

Author: Andreas von Studnitz

Andreas von Studnitz is a Magento developer and one of the Managing Directors at integer_net. His main areas of interest are backend development, Magento consulting and giving developer trainings. He is a Magento 2 Certified Professional Developer Plus and holds several other Magento certifications for both Magento 1 and Magento 2. Andreas was selected as a Magento Master in 2019 and 2020.

More Information · Twitter · GitHub · LinkedIn

Twitter