{"id":1733,"date":"2024-05-16T22:39:18","date_gmt":"2024-05-16T22:39:18","guid":{"rendered":"https:\/\/cppdepend.com\/blog\/?p=1733"},"modified":"2024-05-22T10:49:31","modified_gmt":"2024-05-22T10:49:31","slug":"why-you-should-consider-using-the-c-poco-library","status":"publish","type":"post","link":"https:\/\/cppdepend.com\/blog\/why-you-should-consider-using-the-c-poco-library\/","title":{"rendered":"Why should you consider using the C++ POCO library?"},"content":{"rendered":"\n<p>The <a href=\"https:\/\/pocoproject.org\/\">POCO<\/a> C++ Libraries (POCO stands for &#8220;Portable Components&#8221;) is a collection of open-source C++ class libraries that simplify and accelerate the development of network-centric, portable applications in C++. These libraries provide a wealth of features, ranging from HTTP and HTTPS clients and servers, to XML parsing, to data encryption, to threading support, and much more.<\/p>\n\n\n\n<p>We&#8217;ve relied on the POCO library for over 15 years to verify whether CppDepend accurately evaluates well-implemented projects. Therefore, this assessment is not drawn from a fleeting encounter with the library but from a thorough analysis of its many versions over the past 15 years.<\/p>\n\n\n\n<!--more-->\n\n\n\n<p>Let\u2019s explore a code snippet from the POCO source code:<br><img decoding=\"async\" src=\"https:\/\/www.cppdepend.com\/img\/poco.png\"><\/p>\n\n\n\n<p>This method implementation&nbsp;is characterized by:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Has a few parameters.<\/li>\n\n\n\n<li>Assert technique is used to check if the entries are OK.<\/li>\n\n\n\n<li>The &nbsp;variable names are easy to understand.<\/li>\n\n\n\n<li>The method is short.<\/li>\n\n\n\n<li>&nbsp;No extra comments in the body. The code explains itself.<\/li>\n\n\n\n<li>The function body is well indented.<\/li>\n\n\n\n<li>The STL library is used when needed.<\/li>\n<\/ul>\n\n\n\n<p>When delving into the POCO source code, one can readily observe the consistency of its implementation, as the same best practice rules are applied to each function. Upon exploring the source code, it becomes apparent that POCO is approachable even for C++ beginners. Specifically, POCO has the following characteristics:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>It&#8217;s not over-engineered, and one doesn&#8217;t need to possess advanced C++ skills to comprehend its implementation.<\/li>\n\n\n\n<li>The public classes provided to end users are well-organized and straightforward to utilize.<\/li>\n\n\n\n<li>The design is modular, with the library divided into several projects, each addressing a specific need.<\/li>\n\n\n\n<li>For those seeking advanced utilization of the library, extending, customizing, or modifying the behavior of certain classes is remarkably straightforward.<\/li>\n<\/ol>\n\n\n\n<p>In this post we will focus on some keys of its design:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">ABSTRACT VS INSTABILITY<\/h4>\n\n\n\n<p>Robert C.Martin wrote an interesting&nbsp;article&nbsp;about a set of metrics that can be used to measure the quality of an object-oriented design in terms of the interdependence between the subsystems of that design.<\/p>\n\n\n\n<p>Here\u2019s from the article what he said about the interdependence between modules:<\/p>\n\n\n\n<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<p>What is it that makes a design rigid, fragile and difficult to reuse. It is the interdependence of the subsystems within that design. A design is rigid if it cannot be easily changed. Such rigidity is due to the fact that a single change to heavily interdependent software begins a cascade of changes in dependent modules. When the extent of that cascade of change cannot be predicted by the designers or maintainers the impact of the change cannot be estimated. This makes the cost of the change impossible to estimate. Managers, faced with such unpredictability, become reluctant to authorize changes. Thus the design becomes rigid.<\/p>\n<\/blockquote>\n\n\n\n<p>And to fight the rigidity he introduce metrics like Afferent coupling, Efferent coupling, Abstractness, Instability and the \u201cdistance from main sequence\u201d and the \u201cAbstractness vs Instability\u201d graph.<\/p>\n\n\n\n<p>The \u201cAbstractness vs Instability\u201d graph can be useful to identify the projects&nbsp; difficult to maintain and evolve. Here\u2019s the \u201cAbstractness vs Instability\u201d graph of the POCO library:<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"http:\/\/www.cppdepend.com\/img\/poco\/img9.png\" alt=\"\"\/><\/figure>\n\n\n\n<p>The idea behind this graph is that the more a code element of a program is popular, the more it should be abstract. Or in other words, avoid depending too much directly on implementations, depend on abstractions instead. By popular code element I mean a project (but the idea works also for packages and types) that is massively used by other projects of the program.<br>It is not a good idea to have concrete types very popular in your code base. This provokes some Zones of Pains in your program, where changing the implementations can potentially affect a large portion of the program. And implementations are known to evolve more often than abstractions.<\/p>\n\n\n\n<p>The main sequence line (dotted) in the above diagram shows the how abstractness and instability should be balanced. A stable component would be positioned on the left. If you check the main sequence you can see that such a component should be very abstract to be near the desirable line \u2013 on the other hand, if its degree of abstraction is low, it is positioned in an area that is called the \u201czone of pain\u201d.<\/p>\n\n\n\n<p>Only the Fondation project is inside the zone of pain , which is normal because it\u2019s very used by the other projects. and contains mostly utility classes which are not abstracts.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">TYPE COHESION<\/h4>\n\n\n\n<p>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-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types. LCOMHS value higher than 1 should be considered alarming.<\/p>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"http:\/\/www.cppdepend.com\/img\/poco\/query8.jpg\" alt=\"\"\/><\/figure>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"http:\/\/www.cppdepend.com\/img\/poco\/img11.png\" alt=\"\"\/><\/figure>\n\n\n\n<p>Only 1% of types are considered as no cohesive.<\/p>\n\n\n\n<p>In this post, we&#8217;ve offered a brief glimpse into the design of POCO. In upcoming posts, we&#8217;ll explore its design and implementation in greater detail to understand why this library stands out as one of the well-implemented open-source C++ libraries.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The POCO C++ Libraries (POCO stands for &#8220;Portable Components&#8221;) is a collection of open-source C++ class libraries that simplify and accelerate the development of network-centric, portable applications in C++. These libraries provide a wealth of features, ranging from HTTP and HTTPS clients and servers, to XML parsing, to data encryption, to threading support, and much &hellip; <a href=\"https:\/\/cppdepend.com\/blog\/why-you-should-consider-using-the-c-poco-library\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Why should you consider using the C++ POCO library?&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[290,292,67,299,289,32,279,18,287,294,293,284,285,291,302,298,283,297,19,282,300,295,86,301,288,296,286],"class_list":["post-1733","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-abstractness","tag-afferent-coupling","tag-c-2","tag-code-consistency","tag-code-evaluation","tag-code-quality","tag-code-simplicity","tag-cppdepend","tag-data-encryption","tag-design-principles","tag-efferent-coupling","tag-http","tag-https","tag-instability","tag-library-architecture","tag-modular-design","tag-network-centric-applications","tag-object-oriented-design","tag-open-source","tag-poco-libraries","tag-robert-c-martin","tag-single-responsibility-principle","tag-software-development","tag-software-metrics","tag-threading-support","tag-type-cohesion","tag-xml-parsing"],"_links":{"self":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/1733","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/comments?post=1733"}],"version-history":[{"count":3,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/1733\/revisions"}],"predecessor-version":[{"id":1769,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/posts\/1733\/revisions\/1769"}],"wp:attachment":[{"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/media?parent=1733"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/categories?post=1733"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cppdepend.com\/blog\/wp-json\/wp\/v2\/tags?post=1733"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}