Skip to content

Latest commit

 

History

History
53 lines (34 loc) · 2.07 KB

README.md

File metadata and controls

53 lines (34 loc) · 2.07 KB

IOP vs OOP

In the Working Software Conference 2019 (https://www.agilemovement.it/workingsoftware/schedule.html),
I've seen the speech of Claudio Pattarello: IF Oriented vs Object Oriented.
The idea is to show the IF/Catch/Other abuse and how to use alternative patterns
to have a more Object Oriented version.

Since it's an interesting discussion, also if I don't like every
solution proposed, and since the code used in the speech is written
in C# (https://archive.codeplex.com/?p=iopvsoop), I've done a version in Java 8 .
I've try to not alter the code and to make it the more similar I can
to the original version (so, my excuses for some estetics).

If you want to contribute, enriching this repository whit other solutions
without modifing the original code (so separate packages and added tests),
you're welcome!

Thanks to Claudio Pattarello (https://www.agileday.it/front/speakers/claudio-pattarello/)

IDEAs PRESENTED

  1. favor branch-less code using modular arithmetic or other
    intrinsic properties of a model or of a computation

  2. avoid the IF/SWITCH on the enumeration thanks to the polymorphism
    and with the Visitor Pattern

  3. avoid the IF enriching the result of another operation
    via a Decoration Function/Decorator Pattern

  4. avoid using IF to check for NULL.
    The idea is to return a Processor Object and to bound the
    unvoidable Null-Check to the more internal section of the
    code, limiting its visibility/propagation

  5. avoid the use IF on executions that can go wrong
    using a Processor Object. We pay the price of a side-effect
    assignment on a Processor Object

  6. avoid using the Catch of exceptions as IF through
    the use of Processor Object (lambda) and
    Chain of Responsibility Pattern

  7. avoid the IF on the initialization of Singleton or
    other elements when desidered lazy, using Supplier
    which is reassigned at first computation.