I find it sad that this paper mentions two valid critiques of OOP[0][1], yet makes no effort to engage with their specific criticisms. Also, citing Microsoft's COM object system as _the_ example of OOP's great success must mean that the authors are simply ignorant to how bad COM is and why Microsft has ceased anything beyond legacy support for it.<p>Ultimately, I find the thesis of the paper fundamentally wrong for presuming that OOP is somehow more beneficial than other approaches to dynamic dispatch. Moreover, the use of interfaces in thr paper are more restrictive to code structure, and in turn, are more likely hurt code reuse than help it.<p>Interfaces are an inherently weaker form of the age old Operation Code and data packet paradigm. Take the Widget interface the paper gives as an example (page 5). This interface has now been set in stone. Any additions that would be useful for the widget interface, say OnClick(), will require a breaking change. This is because all code using the old interface will have to be updated and recompiled to satisfy the new interface requirements (even if a widget won't functionally change from using said new interface). Meanwhile for code using op codes, a new op code value is defined and nothing in the old code is required to change. (This assumes that this old code will perform a no operation for the new opcode, which historically has been the case for systems that use this method).<p>In fact, Win32 did exactly this opcode and data packet protocol for its message loop to great long term success. They have regularly extended their existing code without breaking backwards compatibility of older versions. The longevity of code in typical OO systems pales in comparison.<p>[0] <a href="https://harmful.cat-v.org/software/OO_programming/why_oo_sucks" rel="nofollow">https://harmful.cat-v.org/software/OO_programming/why_oo_suc...</a>
[1] <a href="http://stlport.org/resources/StepanovUSA.html" rel="nofollow">http://stlport.org/resources/StepanovUSA.html</a>