{"id":1985,"date":"2015-08-15T00:01:23","date_gmt":"2015-08-15T00:01:23","guid":{"rendered":"http:\/\/www.codergears.com\/Blog\/?p=1985"},"modified":"2015-08-16T13:28:33","modified_gmt":"2015-08-16T13:28:33","slug":"with-c17-concepts-we-can-say-goodbye-to-inheritance","status":"publish","type":"post","link":"https:\/\/codergears.com\/Blog\/?p=1985","title":{"rendered":"With the C++17 Concepts we can say goodbye to the class inheritance"},"content":{"rendered":"

Here’s the common definition of the inheritance from wikipedia<\/a>:<\/p>\n

In\u00a0<\/span>object-oriented programming\u00a0(OOP),\u00a0<\/span>inheritance<\/b>\u00a0is when an\u00a0<\/span>object\u00a0or\u00a0<\/span>class\u00a0is based on another object (<\/span>prototypal inheritance) or class (<\/span>class-based inheritance), using the same implementation (inheriting from an object or class) specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior). It is a mechanism for\u00a0<\/span>code reuse\u00a0and to allow independent extensions of the original software via public classes and interfaces.\u00a0<\/span><\/p><\/blockquote>\n

The inheritance is overused in many C++ libraries and every C++ developer must master the inheritance and also the polymorphism mechanism if he chose to adopt the OOP approach. But what’s wrong with the inheritance?<\/p>\n

Short answer<\/em>: Very high coupling<\/strong>.<\/p>\n

Explanation:<\/p>\n

Let’s take as example\u00a0the implementation of a class calculating a tax.<\/p>\n

\"generics1\"<\/a><\/p>\n

 <\/p>\n

The\u00a0CTaxCalculator collaborates only with classes inheriting from \u00a0ICalculator \u00a0and can’t use any other not ICalculator class even if it can help to calculate the Tax. The calculator implementation class will be highly coupled with ICalculator and no possibility to use another class kind unless we introduce many other classes and interfaces to bypass this limitation. For example the adapter pattern<\/a> is a solution to bypass the inheritance high coupling issue. Think about it some GOF design patterns are there to also resolve some issues generated by the inheritance high coupling issue.<\/p>\n

Generic programming to the rescue<\/strong><\/p>\n

Using the generic programming, the same Tax calculator could be implemented like this:<\/p>\n

\"generics2\"<\/a><\/p>\n

 <\/p>\n

The CGenericTaxCalculator class in the other side calculate the tax \u00a0by using\u00a0\u00a0any type capable to calculate the tax and it’s \u00a0not aware about its kind. What’s important is the methods implemented by the type and not the class kind.\u00a0<\/strong>What\u00a0makes the generic programming more natural and flexible. Indeed in\u00a0the first implementation it’s like in the real world, a company searching for a developer\u00a0accept only ones graduated\u00a0from a specific school and reject all the others even if they\u00a0have the skills needed.<\/p>\n

But the flexibility comes with\u00a0a price, the code became hard to understand, Indeed in OOP programming I can just go to the definition of ICalculator to know what we wait for this type. It’s not the case in generic programming, it’s difficult to know what we expect exactly from the template parameter? Which members\u00a0must contains? Which constraints must be satisfied?<\/p>\n

C++17 concepts to the rescue.<\/strong><\/p>\n

From this interesting article<\/a>\u00a0about C++17 concepts:<\/p>\n

\n

Concept<\/i>\u00a0is a term that describes a\u00a0named set of requirements<\/b>\u00a0for a type.<\/p>\n

Formal specification of concepts\u00a0(ISO\/IEC TS 19217) is an experimental technical specification, finalized in 2015, which makes it possible to verify that template arguments satisfy the expectations of a template or function during\u00a0overload resolution\u00a0and\u00a0template specialization.<\/p>\n<\/blockquote>\n

The concepts was planned in the C++11 standards, but it was postponed twice. The good news is that the C++17 will includes this interesting feature.<\/p>\n

With concepts we can resolve the constraints specifications issue to make the code more readable and maintainable. It’s true that Boost provides for many years a concept implementation but adding them to the language will\u00a0make C++ more powerful and unique.<\/p>\n

Summary:<\/strong><\/p>\n

If the inheritance is overused when choosing the OOP approach, what introduce a high coupling between classes and force you to add more classes just to resolve this issue, it’s not the case when choosing to adopt the generic progamming approach. And fortunately the missing piece to implement a readable, maintainable, low coupled code\u00a0will be part of the language soon.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Here’s the common definition of the inheritance from wikipedia: In\u00a0object-oriented programming\u00a0(OOP),\u00a0inheritance\u00a0is when an\u00a0object\u00a0or\u00a0class\u00a0is based on another object (prototypal inheritance) or class (class-based inheritance), using the same implementation (inheriting from an object or class) specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior). It is a mechanism for\u00a0code reuse\u00a0and to allow independent extensions … Continue reading “With the C++17 Concepts we can say goodbye to the class inheritance”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-1985","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1985","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=1985"}],"version-history":[{"count":9,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1985\/revisions"}],"predecessor-version":[{"id":2009,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=\/wp\/v2\/posts\/1985\/revisions\/2009"}],"wp:attachment":[{"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codergears.com\/Blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}