{"id":858,"date":"2019-11-29T21:27:33","date_gmt":"2019-11-29T10:27:33","guid":{"rendered":"http:\/\/juliangamble.com\/blog\/?p=858"},"modified":"2019-11-30T14:12:12","modified_gmt":"2019-11-30T03:12:12","slug":"the-12-aspects-of-object-oriented-programming-and-why-functional-programming-has-a-better-answer-according-to-lawrence-krubner","status":"publish","type":"post","link":"https:\/\/juliangamble.com\/blog\/2019\/11\/29\/the-12-aspects-of-object-oriented-programming-and-why-functional-programming-has-a-better-answer-according-to-lawrence-krubner\/","title":{"rendered":"The 12 Aspects of Object Oriented Programming and Why Functional Programming Has A Better Answer. (According to Lawrence Krubner)"},"content":{"rendered":"\n<p><strong>What is it?<\/strong><\/p>\n\n\n\n<p>These are a set of arguments suggesting that Object Oriented\nProgramming has 12 attributes, the benefits and deficiencies of each, and that\nFunctional Programming addresses each of those. <\/p>\n\n\n\n<p><strong>Where does this come from?<\/strong><\/p>\n\n\n\n<p>This is from a page on the internet for a site that has now been\ntaken offline, but is preserved on The Wayback Machine<\/p>\n\n\n\n<p><a href=\"https:\/\/web.archive.org\/web\/20191004095642\/http:\/\/www.smashcompany.com\/technology\/object-oriented-programming-is-an-expensive-disaster-which-must-end\">https:\/\/web.archive.org\/web\/20191004095642\/http:\/\/www.smashcompany.com\/technology\/object-oriented-programming-is-an-expensive-disaster-which-must-end<\/a><\/p>\n\n\n\n<p><strong>What is the style of writing?<\/strong><\/p>\n\n\n\n<p>It is provocative and argumentative, seeking to make a point\nby exhaustive evidence and reasoning. The original title was \u201cObject Oriented\nProgramming is an Expensive Disaster that Must End\u201d.<\/p>\n\n\n\n<p><br>\n<strong>Why post this?<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>I studied Eiffel at University in the mid 90s,\nand read Bertrand Meyer\u2019s books on Object Oriented Programming and was fascinated\nby the promise of Object Oriented Programming and what it offered.<\/li><li>In 2009 I became fascinated by the promise of functional\nprogramming, and how it offered an alternative to OOP which was the dominant\nparadigm at the time.<\/li><li>Most arguments in favour of Functional\nProgramming start with \u201cthe future is multi-core, and functional programming\nhas a better answer than OOP\u201d. This author starts with: \u201cHere are the 12\nattributes of functional programming, why they\u2019re good, why they\u2019re bad, and\nwhy functional programming has a better answer.\u201d<\/li><li>I don\u2019t necessarily endorse the arguments of the\nauthor in their entirety, but am fascinated by the reasoning, and wanted to\ncapture it and share it for further discussion. <\/li><li>I wanted to summarise the arguments in a table,\nbecause lots of people don\u2019t appreciate reading large slabs of text. <\/li><li>I felt that the strength of the arguments was lost\nin the provocative style of the writer and felt the same arguments could be more\nconvincingly presented. <\/li><li>Even Bertrand Meyer, one of the chief academic\nproponents of Object Oriented Programming, finds himself arguing against the excesses\nof OOP, making the arguments that match the benefits of functional programming<\/li><\/ul>\n\n\n\n<p><strong>Is it pragmatic?<\/strong><\/p>\n\n\n\n<p>This is not answering the question \u201cHow do I make my\nprogram\/lifestyle better?\u201d It answers the question \u201cWhat are the reasons you\nwould consider Functional Programming, looking at the world from an Object Oriented\nProgramming lens?\u201d<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-stripes\"><table class=\"\"><thead><tr><th>Object Oriented Programming Characteristic<\/th><th>   OOP Benefit   <\/th><th>   OOP Limitation   <\/th><th>  Analogue from Functional Programming (or alternative to OOP)   <\/th><\/tr><\/thead><tbody><tr><td><strong>1. Encapsulation<\/strong>   <\/td><td>Protection from unexpected changes to state.   <\/td><td>Solving the state management problem by hiding it.    <\/td><td>Use closures.   <br><br>Design your program not to mutate state.   <br><br>Design your program around transforming the state.    <\/td><\/tr><tr><td><strong>2. Polymorphism<\/strong>   <\/td><td>We want flexibility in the way we dispatch execution.   \u00a0   <\/td><td>Flexible dispatch based on the signature of a method, and   the signature is almost always evaluated in terms of the data-type of the   parameters being handed into the method   <\/td><td>Multi-methods. [In Clojure. Typeclasses in Haskell are   somewhat comparable.]   <\/td><\/tr><tr><td><strong>3. Inheritance<\/strong>   <\/td><td>Treating similar but slightly different things the same   way externally. <br>   <br>Hierarchies of data types.    <\/td><td> Inheritance mixes   together several things, \u2018typeness\u2019 [sic], interface and implementation.    <br><br>\u201cFavour composition over inheritance\u201d (Josh Bloch)   <\/td><td>Define data-type hierarchy independently of functions and   independently of any state.   \u00a0   <\/td><\/tr><tr><td><strong>4. Abstraction<\/strong>    <\/td><td>Use abstraction to decompose complex systems into smaller   components.      <br>   <br>Denotes the essential characteristics of an object that distinguish it from   all other kinds of object and thus provide crisply defined conceptual boundaries.   \u00a0   Dependency injection is an example of depending on   abstractions.<br>   <br>Contract enforcement. <br>   <br>Data hiding.    <\/td><td>Abstraction is not necessarily a subject within OOP. <br>   <br>Bertrand Myer admits that OOP abstractions lead to factories and builders, the   complexity of which lead to Inversion of Control Containers, which lead to   greater use of composition. <br>   <br>The need for design patterns implies a deficiency of abstraction in the   language itself.    <\/td><td>Solve your problem in terms of DSLs.    \u00a0   <br>Macro-systems can be a tool for abstraction.   <\/td><\/tr><tr><td><strong>5. Code Re-use<\/strong>   <\/td><td>Objects created for Object Oriented Programs can be reused   in other programs. <br>   <br>Many types, one interface promotes code re-use.    <\/td><td>Inheritance undermines code-reuse.    \u00a0   Code reuse killed off by the amount of ceremony required   to get anything done. (Factory patterns, dependency injection, getters and   setters, annotations, verbose exception handling, etc).<br>   <br>All the specificity of interfaces\/classes kills your code re-use. <br>   <br>To achieve code re-use, you need to write a large number of small classes. <br>   <br>The rigidity of the Open-Closed principle tends to limit code re-use.    <\/td><td>Protocols. [In Clojure. \u00a0Traits in Scala or Typeclasses in Haskell   are somewhat comparable.]<br>   <br>Meta programming. <br>   <br>Closures. <br>   <br>Libraries. <br>   <br>Flexible functions that can work on many data-types.<br>   <br>   <br>   <br>   <br>      <\/td><\/tr><tr><td><strong>6. Design Benefits<\/strong>   <\/td><td>OOP forces planning which leads to better designs with   fewer flaws. <br>   <br>For large programs, OOP programs are easier to program than non-OOP ones.    <\/td><td>\u2018Forced Planning\u2019 is an appeal to Waterfall development   method. Risky because you gain benefits at the end of a long process. Only at   the end of the software delivery can your users give feedback about whether   your software helps them.    \u00a0   <\/td><td>Organisations choose adaptive not predictive development   methods like Agile.   <\/td><\/tr><tr><td><strong>7. Software Maintenance<\/strong>   <\/td><td>Whilst more work went into designing an OOP program, less   work is required to maintain it over time compared to a non-OOP program.    \u00a0   <\/td><td>Maintainability depends on understandability, and OOP is a   graph of mutating state that becomes less understandable as it grows. <br>   <br>OOP tends to be bloated, containing lots of boilerplate code.    <\/td><td>Code written in a different style would be smaller and   easier to think about.    <\/td><\/tr><tr><td><strong>8. Single responsibility principle<\/strong>   <\/td><td>A class should have only one reason to change [structure   of class]. <br>   <br>Objects can be clearly reasoned about because they have focus.    <\/td><td>The reasons a class can change are driven by Conways Law   (ie your program is shaped by the information flows in your organisation.)<br>   <br>Single responsibility principle, gives you more objects, and gives you the responsibility   for setting up all the dependent objects for your object, implying the need   for IOC containers. \u00a0   <\/td><td>You should have functions that operate on a data structure.      <\/td><\/tr><tr><td><strong>9. Open\/closed principle<\/strong>   <\/td><td>Enables low coupling, high cohesion.    <\/td><td>Tends towards having too many small classes. <br>   <br>Conflates three issues that should be separate:<br>   1) establishing a data-type hierarchy<br>   2) enforcing a contract<br>   3) mutating state<br>   <br>Rigidity of this principle limits code re-use.    <\/td><td>Use protocols. [In Clojure. \u00a0Traits in Scala or Typeclasses in Haskell   are somewhat comparable.]   <\/td><\/tr><tr><td><strong>10. Interface segregation principle   <\/strong><\/td><td>Many client-specific interfaces are better than one   general-purpose interface.<br>   <br>No client should be forced to depend on methods it does not use. <br>   <br>Keeps a system decoupled, and so easier to refactor, change and deploy.<br>   <br>Useful \u2018contract\u2019 to describe the intent of the software. \u00a0   <\/td><td>Data structures are spread out across multiple classes   making the intent of the software harder to understand. <br>   <br>   <br>      <\/td><td>Have a well-defined data-structure that many functions can   operate on.    <\/td><\/tr><tr><td><strong>11. Dependency inversion principle   <\/strong><\/td><td>Helps to assemble components from different projects into   a cohesive application.    \u00a0   Provides a common pattern for wiring components together   in a decoupled way. <br>   <br>Solves the problem of instantiating the objects that an object depends upon.    <\/td><td>Solves a problem that only exists in Object Oriented   Programming. IOC is a workaround for OOP.    <\/td><td>Not required because the problem doesn\u2019t exist outside   OOP.    <\/td><\/tr><tr><td><strong>12. Static type checking   <\/strong><\/td><td>Enable the efficient and automatic proof of assertions   about programs. <br>   <br>Enable partial specification of your programs.    <\/td><td>OOP languages lose the benefits of the most advanced type-system   features available in functional languages.    <\/td><td>Use a functional language to get the benefits of the most   advanced type-system features.    \u00a0   <br><br>There are exciting things happening with the Scala cats   libraries and scalaz, inspired from Haskell that this author doesn\u2019t address.   <\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Reference<\/p>\n\n\n\n<p><a href=\"http:\/\/www.smashcompany.com\/technology\/object-oriented-programming-is-an-expensive-disaster-which-must-end\">http:\/\/www.smashcompany.com\/technology\/object-oriented-programming-is-an-expensive-disaster-which-must-end<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>What is it? These are a set of arguments suggesting that Object Oriented Programming has 12 attributes, the benefits and deficiencies of each, and that Functional Programming addresses each of those. Where does this come from? This is from a &hellip; <a href=\"https:\/\/juliangamble.com\/blog\/2019\/11\/29\/the-12-aspects-of-object-oriented-programming-and-why-functional-programming-has-a-better-answer-according-to-lawrence-krubner\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[5],"tags":[17,18,19],"class_list":["post-858","post","type-post","status-publish","format-standard","hentry","category-technology","tag-functional-programming","tag-object-oriented-programming","tag-oop"],"_links":{"self":[{"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/posts\/858","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/comments?post=858"}],"version-history":[{"count":4,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/posts\/858\/revisions"}],"predecessor-version":[{"id":862,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/posts\/858\/revisions\/862"}],"wp:attachment":[{"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/media?parent=858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/categories?post=858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/juliangamble.com\/blog\/wp-json\/wp\/v2\/tags?post=858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}