Александр Пашинский "Reinventing Design Patterns with Java 8"

1. www.luxoft.co
m
REINVENTING DESIGN PATTERNS
WITH JAVA8
Alexander Pashynskiy
LoGeek Night
10 Dec 2015

2. www.luxoft.co
m
About me:
• Lead Software Engineer in Luxoft
• More then 6 years experience in Java
• Agile and Lean practicioner
• Pragmatic and product oriented engineer
• Still learning and learn
Email: hunter041@gmail.com
Twitter: @apashinskiy_cv
Alexander Pashinskiy

3. www.luxoft.co
m
Design Patterns

4. www.luxoft.co
m

5. www.luxoft.co
m

6. www.luxoft.co
m
Not only

7. www.luxoft.co
m
Not only
Many, many more ...

8. www.luxoft.co
m
• OOP (Resource acquisition is initialization,
Servant, DI, Pool Objects, Null object …)
• FP (Functions, Monads, Lenz, Curring, …)
• Concurrency (Double-checked locking, Read-write
lock, Thread-specific storage, …)
• Domain Specific (security, money, …)
• and many, many more

9. www.luxoft.co
m
• Problem - Solution pairs
• Similar (or same) solution - different intention (Strategy,
State …)
• inheritance - composition game (OOP)
• Adding level of indirection
• Almost always trade-off
Design Patterns:

10. www.luxoft.co
m
• 1994 year
• For C++
• OOP
Two main principles:
• "Program to an interface, not an implementation."
• "Favor object composition over class inheritance."
Sad:(
Some GoF patterns do not stick to this principles

11. www.luxoft.co
m
• Not only for data
• BLSP
• Violates “Single Responsibility” and encapsulation
• High Coupling
• Future behavior and frameworks inhereted
• Broken “protected” in Java
• Big hierarchy produces hell
Inheritance

12. www.luxoft.co
m
Evolution

13. www.luxoft.co
m
Lambda -> lightwaight design tool

14. www.luxoft.co
m
Template method

15. www.luxoft.co
m
Template method

16. www.luxoft.co
m
Template method
inheritance
• to create new Mailbox you need inherit from
• behavior is scattered through the class hierarchy
• 2 responsibility (be mail box and filter)
• public abstract class

17. www.luxoft.co
m
Template method
inheritance -> composition

18. www.luxoft.co
m
Template method
inheritance -> composition -> function composition

19. www.luxoft.co
m
Template method
g.filterMailBox(f)
* Not strongly mathematical composition (contains ‘if’ logic)

20. www.luxoft.co
m
Template method
• functional interface
• higher order functions
• default methods
• static methods
• capturing non-final variables

21. www.luxoft.co
m
Decorator

22. www.luxoft.co
m
Decorator

23. www.luxoft.co
m
Decorator
just a function composition
g.andThen(f)

24. www.luxoft.co
m
Chain of Responsibility

25. www.luxoft.co
m
Chain of Responsibility

26. www.luxoft.co
m
Chain of Responsibility
chain of function composition
andThen andThen andThen andThen andThen

27. www.luxoft.co
m
Adapter

28. www.luxoft.co
m
Adapter

29. www.luxoft.co
m
Adapter
intermediate object -> partially applied function

30. www.luxoft.co
m
Partially applied function
IntBinaryOperator add = (x, y) -> x + y ;
IntUnaryOperator add5 = x -> add.applyAsInt(x, 5);
Partial application - process of transforming a
function into a function with less parameters.

31. www.luxoft.co
m
Partially applied function
Supported by java - :: operator
ToIntFunctiont<String> stringLength = String::length;
IntFunction<String> helloSubstring = "hello"::substring;

32. www.luxoft.co
m
Currying
Currying - technique of translating the evaluation of a function that
takes multiple parameters into evaluating a sequence of functions, each
with a single argument.

33. www.luxoft.co
m
Currying + Partial application
• allows to set some (not all) parameters
• let the other parameters to be set later
• partially applied function can be reused and
composed
• Powerful decoupling tool

34. www.luxoft.co
m
Proxy

35. www.luxoft.co
m
Proxy

36. www.luxoft.co
m
Proxy
heavyweight proxy object -> lightwaight lawyer function

37. www.luxoft.co
m
Proxy
Functional lightweight AOP:
• Resource managing
• Transactions
• Logging
• and more ...

38. www.luxoft.co
m
Proxy

39. www.luxoft.co
m
Strategy

40. www.luxoft.co
m
Strategy

41. www.luxoft.co
m
Strategy
library of classes -> library of functions

42. www.luxoft.co
m
Iterator

43. www.luxoft.co
m
Iterator

44. www.luxoft.co
m
Iterator
external iterator

45. www.luxoft.co
m
Iterator
external iterator -> internal iterator

46. www.luxoft.co
m
Iterator
• Streams everywere
• if not - implement Spliterator
• mutable -> immutable
• remove -> filter

47. www.luxoft.co
m
Builder

48. www.luxoft.co
m
Builder

49. www.luxoft.co
m
Builder
just a function

50. www.luxoft.co
m
Builder
say me how -> I will build as you want

51. www.luxoft.co
m
Builder
• No boiler-plate any more
• Simple reusability (again function
composition)
• Nice chaining DSL
• Reusable
• Consumer has internal control on objet

52. www.luxoft.co
m
Paradigm shift:

53. www.luxoft.co
m
Paradigm shift:
object oriented -> function oriented

54. www.luxoft.co
m
Paradigm shift:
inheritance -> composition -> function composition

55. www.luxoft.co
m
Paradigm shift:
data to code -> code to data

56. www.luxoft.co
m
Paradigm shift:
external ... -> internal … (iterator, resource mng, ...)

57. www.luxoft.co
m
• functions
• higher order function
• function composition
• partially applies functions
• currying
• monads
• and more ...
New Designer’s Toolbox

58. www.luxoft.co
m
Design Patterns
communication tool rather
then implementation guide

59. www.luxoft.co
m
“In the book we only tell when to apply pattern, but
we never talk about when to remove a pattern.
Removing a pattern can simplify a system and a
simple solution should almost always win. Coming up
with a simple solutions is the real challenge.”
E.Gamma

60. www.luxoft.co
m
• no silver bullet
• OOP is alive
• GoF “Design Patterns” is still valid
• you just have additional design tools
• almost always trade-off
• use your mind
And remember:

61. www.luxoft.co
m
Thanks!!!