Solving Cross-Cutting Concerns in PHP - DutchPHP Conference 2016
8 likes2,761 views
The document discusses the challenges of managing cross-cutting concerns in PHP applications using the object-oriented programming (OOP) paradigm. It highlights the limitations of OOP in handling essential complexities and introduces the aspect-oriented programming (AOP) paradigm as a solution for better modularity and separation of concerns. Additionally, it presents the Go! AOP framework, which facilitates the implementation of AOP in PHP, and provides examples and best practices for integrating AOP into complex enterprise applications.
![Joe Armstrong
“…You wanted a banana but what you got
[with OOP] was a gorilla holding the banana
and the entire jungle”
10](https://image.slidesharecdn.com/solvingcross-cuttingconcernsinphp-160624113101/85/Solving-Cross-Cutting-Concerns-in-PHP-DutchPHP-Conference-2016-21-320.jpg)
Solving Cross-Cutting Concerns in PHP - DutchPHP Conference 2016
- 1. Solving Cross-Cutting Concerns in PHP Alexander 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
- 37. Code tangling 19
- 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
- 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?
- 84. Method interceptors: 41 Can be a final class or a trait!
- 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
- 95. Текст Circuit breaker Prevents one failure from reoccurring continuously
- 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