Talk about solving cross-cutting concerns in PHP at DutchPHP Conference. Discussed questions: 1) OOP features and limitations 2) OOP patterns for solving cross-cutting concerns 3) Aspect-Oriented approach for solving cross-cutting concerns 4) Examples of using AOP for real life application

1. Solving Cross-Cutting
Concerns in PHP
Alexander Lisachenko

2. About me:
2
lisachenko
lisachenko

3. ‣ Head of Software Architecture
at Alpari (RU) Forex Broker
About me:
2
lisachenko
lisachenko

4. ‣ Head of Software Architecture
at Alpari (RU) Forex Broker
‣ Have worked with computers
since 7 years old
About me:
2
lisachenko
lisachenko

5. ‣ Head of Software Architecture
at Alpari (RU) Forex Broker
‣ Have worked with computers
since 7 years old
‣ Clean code advocate, guru in
enterprise architecture
About me:
2
lisachenko
lisachenko

6. ‣ Head of Software Architecture
at Alpari (RU) Forex Broker
‣ Have worked with computers
since 7 years old
‣ Clean code advocate, guru in
enterprise architecture
‣ Author of the aspect-oriented
framework Go! AOP
http://go.aopphp.com
About me:
2
lisachenko
lisachenko

7. Agenda
3

8. Agenda
‣ Advantages of Object-Oriented Paradigm
3

9. Agenda
‣ Advantages of Object-Oriented Paradigm
‣ Limitations of OOP and how they affect our
application
3

10. Agenda
‣ Advantages of Object-Oriented Paradigm
‣ Limitations of OOP and how they affect our
application
‣ Existing object-oriented ways of solving
cross-cutting concerns
3

11. Agenda
‣ Advantages of Object-Oriented Paradigm
‣ Limitations of OOP and how they affect our
application
‣ Existing object-oriented ways of solving
cross-cutting concerns
‣ Pros and cons: the aspect-oriented
approach of solving cross-cutting concerns
3

12. Agenda
‣ Advantages of Object-Oriented Paradigm
‣ Limitations of OOP and how they affect our
application
‣ Existing object-oriented ways of solving
cross-cutting concerns
‣ Pros and cons: the aspect-oriented
approach of solving cross-cutting concerns
‣ Examples of using aspects in real life
applications
3

13. Текст
Object-Oriented Paradigm
Solution to the complexity

14. 5
Modularity
We connect classes, components, bundles, and
frameworks.

15. 6
Reusability
We use existing code to create new code on the
top.

16. 7
Encapsulation
We hide implementation details from the outside
world.

17. 8
Is it a silver bullet?
Object-Oriented Paradigm

18. 8
Is it a silver bullet?
Object-Oriented Paradigm

19. 8
Is it a silver bullet?
Object-Oriented Paradigm

20. Edsger W. Dijkstra
“Object-oriented programming is an
exceptionally bad idea which could
only have originated in California.”
9

21. Joe Armstrong
“…You wanted a banana but what you got
[with OOP] was a gorilla holding the banana
and the entire jungle”
10

22. What are the problems?
11

23. What are the problems?
‣ Limitation of object-oriented
representation of real life processes
11

24. What are the problems?
‣ Limitation of object-oriented
representation of real life processes
‣ Essential complexity results in strong
coupling between components
11

25. What are the problems?
‣ Limitation of object-oriented
representation of real life processes
‣ Essential complexity results in strong
coupling between components
‣ Essential complexity results in scattered
implementation of our concerns
11

26. Текст
Cross-cutting concerns
What they are and why we should think about
them

27. 13
Cross-cutting concerns are
aspects of a program that affect
other concerns.

28. Cross-cutting concerns - why
they affect our code?
14
Task: Implement an audit system that checks
access permission for each public method over
all classes in our system and then logs this
information into the security journal.

29. Clean model
15

30. Authorization control…
16

31. Authorization control…
16

32. Logging and audit…
17

33. Logging and audit…
17

34. Logging and audit…
17

35. Error handling…
18

36. Error handling…
18

37. Code tangling
19

38. Code scattering
20

39. Текст
OOP ways
What do we have in OOP to fight cross-cutting
concerns?

40. Decorator
Design pattern that allows
behavior to be added to an
individual object, either
statically or dynamically,
without affecting the behavior
of other objects from the
same class.
22

41. 23

42. 23

43. 23

44. 23

45. Decorator
+ Respects LSP - We can pass an instance of a
decorator everywhere the original object is expected.
+ Keeps SRP for the original class because it doesn’t
contain secondary concerns now
- Too many decorator classes for each combination of
concern+concrete interface
- Secondary concerns (authorization, caching, etc.) are
scattered across all decorators
- Additional overhead for calling original methods
24

46. Mediator
Defines an object that
incapsulates all logic of
interactions between objects,
giving them the ability to
work without explicit
references to each other
25

47. 26

48. 26

49. 26

50. 27

51. 27

52. 27

53. Mediator
+ All secondary concerns can be moved to separate
classes without duplication (SRP for secondary
concerns)
+ Keeps SRP for the original class, because it doesn’t
contain secondary concerns now
+ The most flexible way of extending a system
- Requires specific changes in the original class to
perform notification of mediator
- Hard to debug code with complex logic of interaction
because there are no explicit links between objects
28

54. Текст
Take control of everything
What if we combine all the best features of the
decorator and mediator into the one pattern?

55. Aspect-Oriented Paradigm
A programming
paradigm that aims to
increase modularity by
allowing the separation
of cross-cutting
concerns
30

56. Go! AOP Framework
31

57. Go! AOP Framework
31
‣ Inspired by famous AspectJ and Spring
frameworks

58. Go! AOP Framework
31
‣ Inspired by famous AspectJ and Spring
frameworks
‣ Over 800 stargazers on Github - thank you!

59. Go! AOP Framework
31
‣ Inspired by famous AspectJ and Spring
frameworks
‣ Over 800 stargazers on Github - thank you!
‣ Over 200k installations on Packagist

60. Go! AOP Framework
31
‣ Inspired by famous AspectJ and Spring
frameworks
‣ Over 800 stargazers on Github - thank you!
‣ Over 200k installations on Packagist
‣ PHP5.6, PHP7.0 and Opcache compatible

61. Go! AOP Framework
31
‣ Inspired by famous AspectJ and Spring
frameworks
‣ Over 800 stargazers on Github - thank you!
‣ Over 200k installations on Packagist
‣ PHP5.6, PHP7.0 and Opcache compatible
‣ There are bridges for SF2, ZF2, Laravel…

62. Let’s take our clean code…
32

63. Let’s take our clean code…
32

64. Let’s take our clean code…
Method execution is an event
32

65. …and subscribe to our event
33

66. …and subscribe to our event
33

67. …and subscribe to our event
Pointcut - describes list of
interesting events
33

68. …and subscribe to our event
Pointcut - describes list of
interesting events
33

69. …and subscribe to our event
Pointcut - describes list of
interesting events
Joinpoint - defines an event
object
33

70. …and subscribe to our event
Pointcut - describes list of
interesting events
Joinpoint - defines an event
object
33

71. …and subscribe to our event
Pointcut - describes list of
interesting events
Joinpoint - defines an event
object
Advice - event handler
33

72. How it works
34
All aspects (or advisors) are registered in
the aspect kernel

73. How it works
35
The special php://filter stream filter is
registered via stream_filter_register()

74. How it works
36
The composer class loader is replaced
with a weaving proxy

75. How it works
37
Lexical analysis and parsing of AST is
performed (nikic/PHP-Parser)

76. How it works
38
Static reflection is created from the AST
(goaop/parser-reflection)

77. How it works
39
The original class is renamed and replaced with a
new class with additional behavior; stored in the
cache

78. How it works
39
The original class is renamed and replaced with a
new class with additional behavior; stored in the
cache

79. How it works
39
The original class is renamed and replaced with a
new class with additional behavior; stored in the
cache
Simple inheritance

80. How it works
39
The original class is renamed and replaced with a
new class with additional behavior; stored in the
cache
Simple inheritance

81. How it works
39
The original class is renamed and replaced with a
new class with additional behavior; stored in the
cache
Simple inheritance
Overridden method

82. Текст
Go! AOP joinpoints
What can be intercepted?

83. Method interceptors:
41

84. Method interceptors:
41
Can be a final class or a trait!

85. Property interceptors:
42

86. Logic interceptors:
43

87. AOP
+ Keeps SRP for the original class because it doesn’t
contain secondary concerns now
+ All secondary concerns are stored in separate classes
without duplication (SRP for secondary concerns)
+ Very flexible way of extending our system (like mediator
does)
+ Does not require changes in original classes
- No tools to debug AOP code; no help from IDE
- Overhead for AOP initialization and execution
44

88. Go! AOP: Debugging with
XDebug
45

89. Go! AOP: Debugging with
XDebug
45

90. Go! AOP: Plugin for the
PhpStorm
46

91. Pointcut syntax highlighting,
completion and analysis
47

92. Pointcut syntax highlighting,
completion and analysis
47

93. Navigate to advice/advised
elements
48

94. Navigate to advice/advised
elements
48

95. Текст
Circuit breaker
Prevents one failure from reoccurring
continuously

96. Logic of CircuitBreaker
50

97. Logic of CircuitBreaker
50
‣ For each public method execution we count
the number of failures in APC/Memcache.

98. Logic of CircuitBreaker
50
‣ For each public method execution we count
the number of failures in APC/Memcache.
‣ If the number of failures is too high, then we
break the circuit to prevent subsequent failures.

99. Logic of CircuitBreaker
50
‣ For each public method execution we count
the number of failures in APC/Memcache.
‣ If the number of failures is too high, then we
break the circuit to prevent subsequent failures.
‣ If the circuit is broken, then the original method
body should not be executed for the
configured amount of time.

100. Logic of CircuitBreaker
50
‣ For each public method execution we count
the number of failures in APC/Memcache.
‣ If the number of failures is too high, then we
break the circuit to prevent subsequent failures.
‣ If the circuit is broken, then the original method
body should not be executed for the
configured amount of time.
‣ https://github.com/ejsmont-artur/php-circuit-
breaker can be used.

101. Step 1. Define an annotation
51

102. Step 2. Define an aspect
52

103. Step 2. Define an aspect
53

104. Step 2. Define an aspect
53
All methods with «Fuse» annotation

105. Step 2. Define an aspect
53
All methods with «Fuse» annotation

106. Step 2. Define an aspect
53
All methods with «Fuse» annotation

107. Step 2. Define an aspect
53
All methods with «Fuse» annotation

108. Step 3. Use it in your code
54

109. Step 3. Use it in your code
54

110. More examples for AOP
55

111. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard

112. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard
‣ Feature toggle pattern

113. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard
‣ Feature toggle pattern
‣ Authorization control

114. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard
‣ Feature toggle pattern
‣ Authorization control
‣ Traditional caching, logging, transaction
control, security audit

115. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard
‣ Feature toggle pattern
‣ Authorization control
‣ Traditional caching, logging, transaction
control, security audit
‣ Design by contract programming (Php-Deal
library)

116. More examples for AOP
55
‣ Profiling methods with pinba extension and
Intaro Pinboard
‣ Feature toggle pattern
‣ Authorization control
‣ Traditional caching, logging, transaction
control, security audit
‣ Design by contract programming (Php-Deal
library)
‣ Aspect-oriented testing (AspectMock)

117. Conclusion
56

118. Conclusion
56
‣ OOP is a nice tool for solving accidental
complexity but not for essential complexity.

119. Conclusion
56
‣ OOP is a nice tool for solving accidental
complexity but not for essential complexity.
‣ Pay attention to code scattering and code
tangling.

120. Conclusion
56
‣ OOP is a nice tool for solving accidental
complexity but not for essential complexity.
‣ Pay attention to code scattering and code
tangling.
‣ Try to extract secondary concerns into
separate classes via OOP decomposition for
small applications.

121. Conclusion
56
‣ OOP is a nice tool for solving accidental
complexity but not for essential complexity.
‣ Pay attention to code scattering and code
tangling.
‣ Try to extract secondary concerns into
separate classes via OOP decomposition for
small applications.
‣ Try to use AOP for complex enterprise
applications.

122. Thank you for the attention!
https://github.com/goaop
https://github.com/lisachenko
https://twitter.com/lisachenko