Elegant Objects and Cactoos

Elegant Objects and Cactoos

Overview of the EO paradigm and small overview of the Cactoos library for Porto Codes Meetup

64999497a1bea392bb5f23c9353e6c3a?s=128

Filipe Freire

December 21, 2017
Tweet

Transcript

  1. Elegant objects & Cactoos Filipe Freire
 21 December 2017

  2. Quick intro Learner, tester, developer, husband
 OSS contributor 2y work

    as a “coding” tester
 1y work as a developer Currently @ filfreire.com 2
  3. Elegant Objects 3

  4. It’s an OOP paradigm 4

  5. Book Yegor Bugayenko @yegor256 www.yegor256.com 5

  6. Book Yegor Bugayenko @yegor256 www.yegor256.com Set of recommendations: - Cleaner

    code - Better classes - Visible architecture 6
  7. Disclaimer: You can find out more at yegor256.com Youtube @yegor256

    and on the EO books. 7
  8. So, what are the recommendations? 8

  9. Getters Setters Mutable objects Static methods Annotations Data Objects Type

    Casting Etc. 9
  10. Getters Setters Mutable objects Static methods Annotations Data Objects Type

    Casting Etc. 10
  11. Don’t treat objects as 
 data structures bags of data.


    Ever. 11
  12. Maintainability > everything else 12

  13. “Objects as living beings” Birth Working life Retirement 13

  14. Some examples… 14

  15. Birth 15

  16. Code Free Constructors 16

  17. 17

  18. “Object’s name != job title” 18

  19. Object’s name != job title Meaning: Avoid the use of

    “-ER” 19
  20. Helper, Handler, Writer, Reader,
 Converter, Observer, Listener, Sorter, Encoder, Decoder,

    … 20
  21. Helper, Handler, Writer, Reader,
 Converter, Observer, Listener, Sorter, Encoder, Decoder,

    … 21
  22. An object isn’t: 1) A link between worlds 2) A

    collection of procedures 
 plus data 22
  23. An object is: 1) Self-sufficient 2) Representative of 
 encapsulated

    data 23
  24. A Finder of Prime Numbers vs A List of numbers

    that 
 returns only primes 24
  25. Education & Work life 25

  26. No Getters and Setters.
 Not even once. 26

  27. No Getters and Setters
 ?! ?! 27

  28. Again, don’t treat objects as 
 bags of data.
 Ever.

    28
  29. Computer-style: 29

  30. Human-style: 30

  31. “An object works by contracts” 31

  32. “An object works by contracts” Always use interfaces 32

  33. Example “I want results for a Tennis match” Tennis_31Feb.xlsx TENNIS.txt

    tennis_res.json Sources: … 33
  34. Example “I want results for a Tennis match” Tennis_31Feb.xlsx TENNIS.txt

    tennis_res.json Sources: … ExcelTennisMatch TextTennisMatch JsonTennisMatch 34
  35. Example “I want results for a Tennis match” ExcelTennisMatch TextTennisMatch

    JsonTennisMatch TennisMatch GameMatch implement extends 35
  36. Excel, Text, Json, etc. Contract stays the same More Decoupling

    and more Maintainability 36
  37. “A good object should never change his encapsulated state.” 37

  38. “A good object should never change his encapsulated state.” 38

    Be immutable
  39. This can change State is the same 39

  40. Some benefits Thread Safety Avoiding Temporal Coupling Avoiding side effects

    Avoiding identity mutability (more at http://yegor256.com/2014/06/09/objects-should-be-immutable.html) 40
  41. Retirement 41

  42. Don’t accept null arguments Don’t return null 42

  43. - Hello, is it a software department?
 - Yes.
 -

    Let me talk to your employee "Jeffrey" please.
 - Hold the line please...
 - Hello.
 - … 43
  44. - Hello, is it a software department?
 - Yes.
 -

    Let me talk to your employee "Jeffrey" please.
 - Hold the line please...
 - Hello.
 - Are you NULL? (more at http://www.yegor256.com/2014/05/13/why-null-is-bad.html) 44
  45. There’s more to it, Let’s save it for another talk

    45
  46. https://github.com/yegor256/cactoos 46

  47. Useful building blocks from Guava, Apache Commons, JDK
 + EO

    paradigm 47
  48. Meaning… No null No code in constructors No getters and

    setters No mutable objects No static methods, not even private ones (among other stuff) 48
  49. Example 1 49

  50. Example 2 50

  51. Example 3 51

  52. Summing up 52

  53. Maintainability 53

  54. –W. Edwards Deming "Build quality into the product rather than

    trying to test it in later." 54
  55. Quality from the start Force strict control of code quality.

    Ex: Static Analysis -> mandatory 55
  56. Thank you. Questions? filfreire filrfreire filfreire.com 56