Solving cross cutting concerns in PHP - PHPSerbia-2017
0 likes•565 views
The document discusses strategies for addressing cross-cutting concerns in PHP through various programming paradigms, particularly focusing on the limitations of Object-Oriented Programming (OOP) and the advantages of Aspect-Oriented Programming (AOP). It mentions how AOP can separate secondary concerns from primary business logic, improving modularity and reducing code tangling and scattering. The author presents the Go! AOP framework, which enables PHP developers to implement AOP efficiently, along with examples of applications in real-world scenarios.
![Joe Armstrong
“…You wanted a banana but what you got [with OOP] was
a gorilla holding the banana and the entire jungle”
9](https://image.slidesharecdn.com/solvingcross-cuttingconcernsinphp-phpserbia-170807174755/85/Solving-cross-cutting-concerns-in-PHP-PHPSerbia-2017-20-320.jpg)
Solving cross cutting concerns in PHP - PHPSerbia-2017
- 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. 3 Agenda:
- 8. ‣ Advantages of Object-Oriented Paradigm 3 Agenda:
- 9. ‣ Advantages of Object-Oriented Paradigm ‣ Limitations of OOP and how they affect our application 3 Agenda:
- 10. ‣ Advantages of Object-Oriented Paradigm ‣ Limitations of OOP and how they affect our application ‣ Existing object-oriented ways of solving cross- cutting concerns 3 Agenda:
- 11. ‣ 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 Agenda:
- 12. ‣ 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 Agenda:
- 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. Joe Armstrong “…You wanted a banana but what you got [with OOP] was a gorilla holding the banana and the entire jungle” 9
- 21. 10 What are the problems?
- 22. ‣ Limitation of object-oriented representation of real life processes 10 What are the problems?
- 23. ‣ Limitation of object-oriented representation of real life processes ‣ Complexity results in strong coupling between components 10 What are the problems?
- 24. ‣ Limitation of object-oriented representation of real life processes ‣ Complexity results in strong coupling between components ‣ Essential complexity results in scattered implementation of our concerns 10 What are the problems?
- 25. Текст Cross-cutting concerns What they are and why we should think about them
- 26. 12 Cross-cutting concerns are aspects of a program that affect other concerns.
- 27. 13 Task:
- 28. 13 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. Task:
- 29. Clean model 14
- 39. Why this kind of code is bad? 18
- 40. Why this kind of code is bad? 18
- 41. Code tangling 19
- 42. Code tangling 19
- 43. Code tangling 20
- 44. Code tangling 20 - Strong coupling between classes
- 45. Code tangling 20 - Strong coupling between classes - A low degree of code reusability
- 46. Code tangling 20 - Strong coupling between classes - A low degree of code reusability - Difficult evolution of codebase
- 51. Code scattering 22 - Lower productivity (repeated implementation of multiple concerns in one class)
- 52. Code scattering 22 - Lower productivity (repeated implementation of multiple concerns in one class) - Breaks the focus of developers
- 53. Code scattering 22 - Lower productivity (repeated implementation of multiple concerns in one class) - Breaks the focus of developers - More error prone (easy to forget to add somewhere)
- 54. Текст OOP ways What do we have in OOP to fight cross-cutting concerns?
- 55. 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. 24
- 56. 25
- 57. 25
- 58. 25
- 59. 25
- 60. Decorator 26
- 61. Decorator + Respects LSP - We can pass an instance of a decorator everywhere the original object is expected. 26
- 62. 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 26
- 63. 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 26
- 64. 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 26
- 65. 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 26
- 66. Defines an object that incapsulates all logic of interactions between objects, giving them the ability to work without explicit references to each other 27 Mediator
- 67. 28
- 68. 28
- 69. 28
- 70. 29
- 71. 29
- 72. 29
- 73. 29
- 74. 29
- 75. Mediator 30
- 76. + All secondary concerns can be moved to separate classes without duplication (SRP for secondary concerns) Mediator 30
- 77. + 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 Mediator 30
- 78. + 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 Mediator 30
- 79. - Requires specific changes in the original class to perform notification of 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 Mediator 30
- 80. - 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 + 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 Mediator 30
- 81. A programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns Aspect-Oriented Paradigm 31
- 83. ‣ Inspired by famous AspectJ and Spring Java frameworks Go! AOP Framework 32 goaop/framework
- 84. ‣ Inspired by famous AspectJ and Spring Java frameworks ‣ Almost 1K stargazers on Github - thank you! Go! AOP Framework 32 goaop/framework
- 85. ‣ Inspired by famous AspectJ and Spring Java frameworks ‣ Almost 1K stargazers on Github - thank you! ‣ Over 400k installations on Packagist Go! AOP Framework 32 goaop/framework
- 86. ‣ Inspired by famous AspectJ and Spring Java frameworks ‣ Almost 1K stargazers on Github - thank you! ‣ Over 400k installations on Packagist ‣ PHP5.6, PHP7.x and Opcache compatible Go! AOP Framework 32 goaop/framework
- 87. ‣ Inspired by famous AspectJ and Spring Java frameworks ‣ Almost 1K stargazers on Github - thank you! ‣ Over 400k installations on Packagist ‣ PHP5.6, PHP7.x and Opcache compatible ‣ There are bridges for Symfony, Zend, Laravel… Go! AOP Framework 32 goaop/framework
- 88. Let’s take our clean code one more time… 33
- 89. Let’s take our clean code one more time… 33
- 90. Let’s take our clean code one more time… Method execution is an event! 33
- 91. …and subscribe to our event 34
- 92. …and subscribe to our event 34
- 93. …and subscribe to our eventPointcut - describes list of interesting events 34
- 94. …and subscribe to our eventPointcut - describes list of interesting events 34 Joinpoint - defines an event object
- 95. …and subscribe to our eventPointcut - describes list of interesting events Advice - event handler 34 Joinpoint - defines an event object
- 96. Aspect VS Event Listener 35
- 97. Aspect VS Event Listener 35
- 98. Aspect VS Event Listener 35
- 99. Aspect VS Event Listener 35
- 100. Текст How AOP works and modifies your original code?
- 101. 37 All aspects (or advisors) are registered in the aspect kernel
- 102. 37 All aspects (or advisors) are registered in the aspect kernel
- 103. 38 The special php://filter stream filter is registered via stream_filter_register()
- 104. 39 The composer class loader is replaced with a weaving proxy
- 105. 40 Lexical analysis and parsing of source code into the AST is performed (nikic/PHP-Parser)
- 106. 41 Static reflection is created from the AST (goaop/parser-reflection)
- 107. 41 Static reflection is created from the AST (goaop/parser-reflection)
- 108. 41 Static reflection is created from the AST (goaop/parser-reflection)
- 109. 41 Static reflection is created from the AST (goaop/parser-reflection)
- 110. 42 The original class is renamed and replaced with a new class with additional behavior; stored in the cache
- 111. 42 The original class is renamed and replaced with a new class with additional behavior; stored in the cache
- 112. 42 The original class is renamed and replaced with a new class with additional behavior; stored in the cache Same class name!
- 113. 42 The original class is renamed and replaced with a new class with additional behavior; stored in the cache Original class renamedSame class name!
- 114. 42 The original class is renamed and replaced with a new class with additional behavior; stored in the cache Original class renamed Overridden method Same class name!
- 118. Method interceptors: 44 Can be a final class or a trait!
- 127. AOP 47
- 128. AOP 47 + Keeps SRP for the original class because it doesn’t contain secondary concerns now
- 129. AOP 47 + 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)
- 130. AOP 47 + 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)
- 131. AOP 47 + 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 👍
- 132. - No tools to debug AOP code; no help from IDE AOP 47 + 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 👍
- 133. - No tools to debug AOP code; no help from IDE - Overhead for AOP initialization and execution AOP 47 + 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 👍
- 134. 48 - No tools to debug AOP code - No help from IDE
- 135. 48 - No tools to debug AOP code - No help from IDE
- 136. Plugin for the PhpStorm 👍 49
- 137. Plugin for the PhpStorm 👍 49
- 140. Pointcut syntax highlighting, completion and analysis 51
- 141. Pointcut syntax highlighting, completion and analysis 51
- 142. Navigate to advice/advised elements 52
- 143. Navigate to advice/advised elements 52
- 144. Текст Logging Automatic logging of methods execution
- 145. Step 1. Define an annotation 54
- 146. Step 1. Define an annotation 54
- 147. Step 2. Define an aspect 55
- 148. Step 2. Define an aspect 55
- 149. Step 2. Define an aspect 56
- 150. Step 2. Define an aspect 56
- 151. Step 2. Define an aspect 56 All methods with «Loggable» annotation
- 152. Step 2. Define an aspect 56 All arguments for this method call
- 153. Step 2. Define an aspect 56 All parameter names (Reflection)
- 154. Step 2. Define an aspect 56 Preparing context for logging
- 155. Step 2. Define an aspect 56 Log this information
- 156. Step 3. Use it in your code 57
- 157. Step 3. Use it in your code 57 Import «Loggable» annotation
- 158. Step 3. Use it in your code 57 Define additional log info
- 159. Текст Caching Automatic caching of methods
- 160. Step 1. Define an annotation 59
- 161. Step 2. Define an aspect 60
- 162. Step 2. Define an aspect 60
- 163. Step 2. Define an aspect 60 All methods with «Cacheable» annotation
- 164. Step 2. Define an aspect 60 Calculate cache key and check it
- 165. Step 2. Define an aspect 60 Execute original method
- 166. Step 2. Define an aspect 60
- 167. Step 3. Use it in your code 61
- 168. Step 3. Use it in your code 61
- 169. Step 3. Use it in your code 61 Define additional cache info
- 170. Текст Async methods Runtime transformation of methods into async methods
- 171. Step 1. Define an annotation 63
- 172. Step 2. Define an aspect 64
- 173. Step 2. Define an aspect 64
- 174. Step 2. Define an aspect 64 All methods with «Async» annotation
- 175. Step 2. Define an aspect 64 Record each call with arguments
- 176. Step 2. Define an aspect 64 Prevent execution of original method
- 177. Step 2. Define an aspect 64 Return «our» value
- 178. Step 2. Define an aspect 65
- 179. Step 2. Define an aspect 65
- 180. Step 2. Define an aspect 65
- 181. Step 2. Define an aspect 65
- 182. Step 2. Define an aspect 65 Finish FASTCGI Request
- 183. Step 2. Define an aspect 65 Execute delayed methods
- 184. More examples for AOP 66
- 185. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard
- 186. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard ‣ Feature toggle pattern
- 187. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard ‣ Feature toggle pattern ‣ Authorization control
- 188. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard ‣ Feature toggle pattern ‣ Authorization control ‣ Traditional transaction control, security audit
- 189. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard ‣ Feature toggle pattern ‣ Authorization control ‣ Traditional transaction control, security audit ‣ Design by contract programming (Php-Deal library)
- 190. More examples for AOP 66 ‣ Profiling methods with pinba extension and Intaro Pinboard ‣ Feature toggle pattern ‣ Authorization control ‣ Traditional transaction control, security audit ‣ Design by contract programming (Php-Deal library) ‣ Aspect-oriented testing (AspectMock)
- 191. Conclusion 67
- 192. Conclusion 67 ‣ OOP is a nice tool for solving accidental complexity but not for essential complexity.
- 193. Conclusion 67 ‣ OOP is a nice tool for solving accidental complexity but not for essential complexity. ‣ Pay attention to code scattering and code tangling.
- 194. Conclusion 67 ‣ 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.
- 195. Conclusion 67 ‣ 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.
- 196. Thank you for the attention! https://github.com/goaop https://github.com/lisachenko https://twitter.com/lisachenko