{"id":729,"date":"2018-03-16T23:26:41","date_gmt":"2018-03-16T23:26:41","guid":{"rendered":"http:\/\/cppdepend.com\/blog\/?p=729"},"modified":"2019-03-13T22:52:31","modified_gmt":"2019-03-13T22:52:31","slug":"oop-vs-generics-is-vs-has-approach","status":"publish","type":"post","link":"https:\/\/cppdepend.com\/blog\/oop-vs-generics-is-vs-has-approach\/","title":{"rendered":"OOP vs Generics : “Is” vs “Has” approach."},"content":{"rendered":"

As Bjarne Stroustrup points out, “C++ is a multi-paradigmed language.” It supports many different styles of programs, or paradigms, and object-oriented programming is only one of these. Some of the others are structured programming and generic programming.<\/p>\n

And as Thomas Becker\u00a0explains in this interesting\u00a0article, there’s a tension between the generic programming and OOP. And here’s from the article the opinion of Alexander Stepanov and elder statesman about OOP:\u00a0<\/p>\n

Let us start with a little trivia quiz. Who said the following things about object-oriented programming?\r\n\r\n\"I find OOP technically unsound.\"\r\n\r\n\"I find OOP philosophically unsound.\"\r\n\r\n\"I find OOP methodologically wrong.\"\r\n\r\n\"I have yet to see an interesting piece of code that comes from these OO people.\"\r\n\r\n\"I think that object orientedness is almost as much of a hoax as artificial intelligence.\"\r\n\r\nAll the quotes above are from an interview with Alexander Stepanov, the inventor of the STL and elder statesman of generic programming.\r\n\r\nTo have a concrete idea about the generics flexibility, let\u2019s compare the implementation of a class calculating a tax in OOP and generic programming.<\/pre>\n
Let’s discover a major difference\u00a0between the two methodologies which could explain the opinion of Alexander Stepanov about the OOP approach.\u00a0 For that let’s take as example\u00a0this basic tax calculator<\/p>\n
\"generics1\"<\/a><\/p>\n
The\u00a0CTaxCalculator collaborate only with classes of ICalculator\u00a0kind. Indeed, we have to\u00a0inherit from ICalculator and override some virtual methods to implement our algorithm.<\/p>\n
On the other side here’s an example of the\u00a0 generic TaxCalculator<\/p>\n
\"generics2\"<\/a><\/p>\n
The CGenericTaxCalculator class does not collaborate only with a specific\u00a0class\u00a0kind but with any type capable to calculate the tax,\u00a0 it \u2019s not\u00a0aware\u00a0of\u00a0its kind.<\/p>\n
The OOP approach is more an “Is oriented approach<\/strong>“, the inheritance is overused and in almost all the OOP code each class A collaborate with another class B if B is<\/strong>\u00a0a kind of another class, abstract or not.<\/p>\n
On the other side, for the generic approach a class A collaborate with B if B has\u00a0<\/strong>some specific methods and fields, no need to inherit from a specific class.<\/p>\n
This\u00a0makes the generic programming more natural and flexible, it gives to the developer the possibility to adopt a “has oriented approach<\/strong>“, the OOP is more rigid due to the high coupling generated by the inheritance which forces the developer to follow an “Is oriented approach<\/strong>“.<\/p>\n
Think about\u00a0it the “has oriented\u00a0approach<\/strong> ” is the more natural one. Indeed in the real world, I collaborate with a person who has<\/strong>\u00a0specific skills, no matter if it is<\/strong> from a specific family.<\/p>\n
The fact that the generic programming is more flexible than OOP makes it the preferred\u00a0choice for the modern C++ design as pointed by\u00a0\u00a0Andrei Alexandrescu:<\/p>\n
Modern C++ Design defines and systematically uses\u00a0generic components<\/i>\u00a0- highly flexible design artifacts that are mixable and matchable to obtain rich behaviors with a small, orthogonal body of code.<\/pre>\n
Three\u00a0assertions are interesting in his point of view:<\/p>\n