{"id":2068,"date":"2024-09-15T08:39:40","date_gmt":"2024-09-15T08:39:40","guid":{"rendered":"https:\/\/cppdepend.com\/blog\/?p=2068"},"modified":"2024-09-15T08:39:47","modified_gmt":"2024-09-15T08:39:47","slug":"a-look-inside-the-macchina-sdk-source-code-clean-design-and-implementation","status":"publish","type":"post","link":"https:\/\/cppdepend.com\/blog\/a-look-inside-the-macchina-sdk-source-code-clean-design-and-implementation\/","title":{"rendered":"A Look Inside the Macchina SDK Source Code: Clean Design and Implementation."},"content":{"rendered":"\n

In C++, many libraries can aid in implementing an IoT application, but most are low-level. For a high-level SDK,\u00a0Macchina.io<\/a>\u00a0is an excellent choice, especially if you seek a robust framework that simplifies IoT application creation.<\/p>\n\n\n\n

Macchina is not only a perfect solution for IoT applications but it’s also a well designed and implemented project, so the SDK users could easily understand and customize its behavior.<\/p>\n\n\n\n

Let’s take a look inside the Macchina source code using CppDepend and discover some facts about its design and implementation.<\/p>\n\n\n\n\n\n\n\n

Clean Design<\/strong><\/p>\n\n\n\n

When designing a C++ project with a well-organized folder structure, it’s important to consider modularity<\/strong>, maintainability<\/strong>, and scalability<\/strong>. Organizing your code by folders allows you to separate concerns, making it easier to navigate, modify, and extend.<\/p>\n\n\n\n

As we can discover from the following DSM. The Macchina SDK is well structured using folders:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The technical layer based on the POCO library is isolated in the platform folder. The\u00a0POCO C++ Libraries<\/strong>\u00a0are powerful cross-platform open-source C++ libraries for building network- and internet-based applications that run on desktop, server, mobile, IoT, and embedded systems.<\/p>\n\n\n\n

Here’s the dependency graph of some POCO libraries. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Let’s take a look inside the Foundation project to explore its structure:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

<\/p>\n\n\n\n

The namespaces in the source code are used for 3 differents goals:\u00a0<\/p>\n\n\n\n

1- Modularize the application<\/strong><\/p>\n\n\n\n

Modern C++ librarires use extensively the namespaces to modalirize their code base, and they use the  \u201cNamespace-by-feature\u201d approach. Namespace-by-feature uses namespaces to reflect the feature set. It places all items related to a single feature (and only that feature) into a single namespace. This results in namespaces with high cohesion and high modularity, and with minimal coupling between namespaces. Items that work closely together are placed next to each other.<\/p>\n\n\n\n

2- Anonymous namespace.<\/strong><\/p>\n\n\n\n

Namespace with no name avoids making global static variable. The \u201canonymous\u201d namespace you have created will only be accessible within the file you created it in.<\/p>\n\n\n\n

3- Hiding details by convention<\/strong><\/p>\n\n\n\n

In C++ where there’s no way to hide public types to the library user (In\u00a0C# the \u201cinternal\u201d keyword did the job). It\u2019s\u00a0interesting to find a way to inform the library user that he dont need to use directly some specific types because they concern only the implementation.\u00a0<\/p>\n\n\n\n

A common idiom in modern C++, pioneered by the developers of the Boost libraries, is to separate symbols that form part of the implementation of your module (that is, don\u2019t form part of the public API) but that have to be publicly available into a separate sub-namespace, by convention named detail.<\/p>\n\n\n\n

The namespaces Poco.Details and Poco.Dynamic.Impl are used to hide the implmentation by convention.<\/p>\n\n\n\n

Loose coupling enforced for more flexibility<\/strong><\/p>\n\n\n\n

Loose coupling is desirable because changes in one area of an application will require fewer changes in other parts of the system. In the long run, this can save significant time, effort, and costs associated with modifying and adding new features to the application.<\/p>\n\n\n\n

Loose coupling can be achieved by using abstract classes or generic types and methods.<\/p>\n\n\n\n

The Macchina source code contains more than 300 abstract classes:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

For example, the client authenticator class is an abstract class that allows for multiple implementations, providing flexibility in the user authentication feature.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

High cohesion is enforced<\/strong> <\/p>\n\n\n\n

The single responsibility principle states that a class should not have more than one reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0\u20131]. The LCOM HS (HS stands for Henderson-Sellers) takes its values in the range [0\u20132]. A LCOM HS value highest than 1 should be considered alarming. Here are to compute LCOM metrics:<\/p>\n\n\n\n

\n

LCOM = 1 \u2014 (sum(MF)\/M*F)
LCOM HS = (M \u2014 sum(MF)\/F)(M-1)<\/em><\/p>\n<\/blockquote>\n\n\n\n

Where:<\/p>\n\n\n\n