{"id":2340,"date":"2016-05-18T22:03:54","date_gmt":"2016-05-18T22:03:54","guid":{"rendered":"http:\/\/www.codergears.com\/Blog\/?p=2340"},"modified":"2018-04-04T13:31:00","modified_gmt":"2018-04-04T13:31:00","slug":"do-the-developers-have-less-interest-in-design-patterns-or-they-are-more-pragmatic","status":"publish","type":"post","link":"https:\/\/codergears.com\/Blog\/?p=2340","title":{"rendered":"Do the developers have less interest in design patterns or they are more pragmatic?"},"content":{"rendered":"<p style=\"color: #555555;\">The majority of developers have already heard about the design patterns,\u00a0<a style=\"color: #2970a6;\" href=\"http:\/\/en.wikipedia.org\/wiki\/Design_Patterns\">GOF(Gang Of Four)<\/a>\u00a0patterns are the most popularized, and each developer has his way to learn them , we can enumerate:<\/p>\n<ul style=\"color: #555555;\">\n<li>Reading a book.<\/li>\n<li>From web sites.<\/li>\n<li>From a collegue.<\/li>\n<li>Doing a training.<\/li>\n<\/ul>\n<p><span style=\"color: #555555;\"><span id=\"more-741\"><\/span>Regardless of the method chose, we can learn by heart the patterns and spent hours to memorize their UML diagrams, but when we need to use them in a real project, it becomes more problematic.<\/span>\u00a0And r<span style=\"color: #555555;\">elated to google trends the design patterns are not more popular as before.\u00a0<\/span><!--more--><\/p>\n<p style=\"color: #333333;\"><a href=\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/trend1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2348\" src=\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/trend1.png\" alt=\"trend\" width=\"832\" height=\"258\" \/><\/a><\/p>\n<p style=\"color: #333333;\">After the analysis of many C++ open source projects using <a href=\"http:\/\/www.cppdepend.com\">CppDepend<\/a>. We can confirm this trend. Indeed\u00a0we discovered that the design patterns are not widely used \u00a0even for the known projects. However \u00a0some basic concepts like the lose coupling and the high cohesion are widely used in many projects.<\/p>\n<p style=\"color: #333333;\">\u00a0<strong>Coupling<\/strong><\/p>\n<p style=\"color: #555555;\">Low coupling is desirable because a change in one area of an application will require fewer changes throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.<\/p>\n<p style=\"color: #555555;\">Low coupling could be acheived by using abstract classes.\u00a0Here are three key benefits derived from using them:<\/p>\n<ul style=\"color: #555555;\">\n<li>An abstract class provides a way to define a contract that promotes reuse. If an object implements an abstract class\u00a0then that object is to conform to a standard. An object that uses another object is called a consumer. An abstract class\u00a0is a contract between an object and its consumer.<\/li>\n<li>An abstract class\u00a0also provides a level of abstraction that makes programs easier to understand. abstract class allow developers to start talking about the general way that code behaves without having to get in to a lot of detailed specifics.<\/li>\n<li>An abstract class\u00a0enforce low coupling between components, what\u2019s make easy to protect the abstract class\u00a0consumer from any implementation changes in the classes implementing the abstract classes.<\/li>\n<\/ul>\n<p style=\"color: #555555;\">Let\u2019s search for all abstract classes defined by OpenCV\u00a0:<\/p>\n<p style=\"color: #555555;\"><a href=\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/opencv6.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-568\" src=\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/opencv6.png\" alt=\"opencv6\" width=\"387\" height=\"512\" \/><\/a><\/p>\n<p style=\"color: #555555;\">\n<p style=\"color: #555555;\">OpenCV defines many abstract classes to enforce loose coupling.<\/p>\n<p style=\"color: #555555;\">If our primary goal is to enforce loose coupling, there\u2019s a common mistake when using abstract classes,\u00a0that could kill the utility of using them. It\u2019s the using of the concrete classes instead of abstract ones, to explain better this problem let\u2019s take the following example:<\/p>\n<p style=\"color: #555555;\">The class A implements the abstract class\u00a0IA which\u00a0contains the calculate() method, the consumer class C is implemented like this<\/p>\n<pre style=\"color: #555555;\">public class C\r\n{\r\n   \u2026.\r\n   public:\r\n      void calculate()\r\n      {\r\n        \u2026..\r\n        m_a-&gt;calculate();\r\n        \u2026.\r\n       }\r\n       A* m_a;\r\n\u00a0};<\/pre>\n<p style=\"color: #555555;\">The class\u00a0C instead of referencing the abstract class\u00a0IA, it references the class A, in this case we lose the low coupling benefit, this implementation has two major drawbacks:<\/p>\n<ul style=\"color: #555555;\">\n<li>If we decide to use another implementation of IA, we must change the code of C class.<\/li>\n<li>If some methods are added to A not existing in IA, and C use them, we also lose the contract benefit of using interfaces.<\/li>\n<\/ul>\n<p style=\"color: #555555;\">C# introduced the\u00a0<a style=\"color: #2970a6;\" href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/aa288461(v=vs.71).aspx\">explicit interface implementation<\/a>\u00a0capability to the language to ensure that a method from the IA will be never called from a reference to concrete classes, but only from a reference to the interface. This technique is very useful to protect developers from losing the benefit of using interfaces.<\/p>\n<p style=\"color: #333333;\">\u00a0<strong>Cohesion<\/strong><\/p>\n<p style=\"color: #333333;\">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 LCOM HS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. A LCOM HS value highest than 1 should be considered alarming. Here are \u00a0to compute LCOM metrics:<\/p>\n<blockquote style=\"color: #333333;\"><p>LCOM = 1 \u2013 (sum(MF)\/M*F)<br \/>\nLCOM HS = (M \u2013 sum(MF)\/F)(M-1)<\/p><\/blockquote>\n<p style=\"color: #333333;\">Where:<\/p>\n<ul style=\"color: #333333;\">\n<li>M is the number of methods in class (both static and instance methods are counted, it includes also constructors, properties getters\/setters, events add\/remove methods).<\/li>\n<li>F is the number of instance fields in the class.<\/li>\n<li>MF is the number of methods of the class accessing a particular instance field.<\/li>\n<li>Sum(MF) is the sum of MF over all instance fields of the class.<\/li>\n<\/ul>\n<p style=\"color: #333333;\">The underlying idea behind these formulas can be stated as follow: a class is utterly cohesive if all its methods use all its\u00a0<span style=\"color: #474747;\">methods use all its instance fields, which means that sum(MF)=M*F and then LCOM = 0 and LCOMHS = 0.<\/span><\/p>\n<p style=\"color: #555555;\">LCOMHS value higher than 1 should be considered alarming.<\/p>\n<p style=\"color: #555555;\">Here are the less cohesive classes from the Unreal Engine source code:<\/p>\n<p style=\"color: #555555;\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1030\" src=\"http:\/\/www.codergears.com\/Blog\/wp-content\/uploads\/unreal36.png\" alt=\"unreal36\" width=\"619\" height=\"496\" \/><\/p>\n<p style=\"color: #555555;\">Only few types are not cohesive.<\/p>\n<p><strong>\u00a0Abstract vs instability: POCO case study<\/strong><\/p>\n<p>Robert C.Martin wrote an interesting\u00a0<a href=\"http:\/\/www.objectmentor.com\/resources\/articles\/oodmetrc.pdf\">article<\/a>\u00a0about 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<p>Here\u2019s from the article what he said about the interdependence between modules:<\/p>\n<blockquote><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><\/blockquote>\n<p style=\"color: #333333;\">For POCO here\u2019s the \u201cAbstractness vs Instability\u201d graph:<\/p>\n<p style=\"color: #333333;\"><img decoding=\"async\" class=\"bordered\" src=\"http:\/\/www.cppdepend.com\/img\/poco\/img9.png\" alt=\"\" width=\"500px\" \/><\/p>\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 \/>\nIt 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<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<p><strong>Conclusion:<\/strong><\/p>\n<p style=\"color: #333333;\"><span style=\"color: #555555;\">What\u2019s very important is not to know exactly pattern names and how to implement them as described in the documentation, but what\u2019s more relevant is the motivation\u00a0behind each pattern,\u00a0it\u2019s from motivations that we invent the patterns.<\/span><\/p>\n<p>Coupling, cohesion, abstractness and instability \u00a0are some\u00a0powerful concepts to enforce the design of your OOP project, Many khown C++ projects use only the singleton from the GOF. But they enforce the design using some basic concepts, they follow more a pragmatic approach.<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The majority of developers have already heard about the design patterns,\u00a0GOF(Gang Of Four)\u00a0patterns are the most popularized, and each developer has his way to learn them , we can enumerate: Reading a book. From web sites. From a collegue. Doing a training. Regardless of the method chose, we can learn by heart the patterns and &hellip; <a href=\"https:\/\/codergears.com\/Blog\/?p=2340\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Do the developers have less interest in design patterns or they are more pragmatic?&#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":[],"class_list":["post-2340","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/2340","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2340"}],"version-history":[{"count":12,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/2340\/revisions"}],"predecessor-version":[{"id":2356,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/2340\/revisions\/2356"}],"wp:attachment":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2340"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2340"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2340"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}