Elegant Objects and Cactoos

Transcript

1. 1.

   Elegant objects & Cactoos Filipe Freire
 21 December 2017

2. 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. 3.

   Elegant Objects 3

4. 4.

   It’s an OOP paradigm 4

5. 5.

   Book Yegor Bugayenko @yegor256 www.yegor256.com 5

6. 6.

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

   code - Better classes - Visible architecture 6
7. 7.

   Disclaimer: You can find out more at yegor256.com Youtube @yegor256

   and on the EO books. 7
8. 8.

   So, what are the recommendations? 8

9. 9.

   Getters Setters Mutable objects Static methods Annotations Data Objects Type

   Casting Etc. 9
10. 10.

    Getters Setters Mutable objects Static methods Annotations Data Objects Type

    Casting Etc. 10
11. 11.

    Don’t treat objects as 
 data structures bags of data.


    Ever. 11
12. 12.

    Maintainability > everything else 12

13. 13.

    “Objects as living beings” Birth Working life Retirement 13

14. 14.

    Some examples… 14

15. 15.

    Birth 15

16. 16.

    Code Free Constructors 16

17. 17.

    17

18. 18.

    “Object’s name != job title” 18

19. 19.

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

    “-ER” 19
20. 20.

    Helper, Handler, Writer, Reader,
 Converter, Observer, Listener, Sorter, Encoder, Decoder,

    … 20
21. 21.

    Helper, Handler, Writer, Reader,
 Converter, Observer, Listener, Sorter, Encoder, Decoder,

    … 21
22. 22.

    An object isn’t: 1) A link between worlds 2) A

    collection of procedures 
 plus data 22
23. 23.

    An object is: 1) Self-sufficient 2) Representative of 
 encapsulated

    data 23
24. 24.

    A Finder of Prime Numbers vs A List of numbers

    that 
 returns only primes 24
25. 25.

    Education & Work life 25

26. 26.

    No Getters and Setters.
 Not even once. 26

27. 27.

    No Getters and Setters
 ?! ?! 27

28. 28.

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

    28
29. 29.

    Computer-style: 29

30. 30.

    Human-style: 30

31. 31.

    “An object works by contracts” 31

32. 32.

    “An object works by contracts” Always use interfaces 32

33. 33.

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

    tennis_res.json Sources: … 33
34. 34.

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

    tennis_res.json Sources: … ExcelTennisMatch TextTennisMatch JsonTennisMatch 34
35. 35.

    Example “I want results for a Tennis match” ExcelTennisMatch TextTennisMatch

    JsonTennisMatch TennisMatch GameMatch implement extends 35
36. 36.

    Excel, Text, Json, etc. Contract stays the same More Decoupling

    and more Maintainability 36
37. 37.

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

38. 38.

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

    Be immutable
39. 39.

    This can change State is the same 39

40. 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. 41.

    Retirement 41

42. 42.

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

43. 43.

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

    Let me talk to your employee "Jeffrey" please.
 - Hold the line please...
 - Hello.
 - … 43
44. 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. 45.

    There’s more to it, Let’s save it for another talk

    45
46. 46.

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

47. 47.

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

    paradigm 47
48. 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. 49.

    Example 1 49

50. 50.

    Example 2 50

51. 51.

    Example 3 51

52. 52.

    Summing up 52

53. 53.

    Maintainability 53

54. 54.

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

    trying to test it in later." 54
55. 55.

    Quality from the start Force strict control of code quality.

    Ex: Static Analysis -> mandatory 55
56. 56.

    Thank you. Questions? filfreire filrfreire filfreire.com 56