This page will document the actions done to minimize the coupling in the source code. Usually, in software development, it is considered good practice to reduce coupling. Coupling can be described as the level of dependency between modules. The lower the level of dependency, the easier it is for a developer to modify the software.
In order to do so, the team has identified five series of actions that can help reduce coupling:
The classes of the module respect encapsulation priciple by declaring their attributes private and implementing the needed accessors (getters/setters) as public functions. Also, it is good practice to implement the module's code in the proc_image_processing namespace.
We are already using a form a intermediary in the code. In fact, by default, when working with ROS, we have to use a publish-subscribe mechanism. A ROS node can act as a publisher. It will publish messages to a topic. Another ROS node can act as a subscriber and receives messages from this topic. Hence, this kind of architecture breaks down the dependency between the publisher node and the subscriber node. The only dependency left is to make sure that the publisher publishes the right type of message on the topic and that the subscriber receives the right type of message from the topic.
Here is a diagram explaining some of the topics used in the code.
Refactoring is another tactic used to reduce coupling inside code. The principle is very simple: we want to put code that does the same thing in one file. In other words, we don't want to make the same change on multiple files when a change occurs.
The changes we made are the following:
Like the other SONIA's repositories, proc_image_processing is laying on sonia_common who abstract common services. Moreover, this module use sonia_common for managing filterchains, configurations, macros, vision target, execute commands, publishing and managing ROS service server.