Object Calisthenics for Magento - MageTitans USA 2017
•
2 likes•702 views
The document discusses Object Calisthenics, which are a set of 9 simple rules for writing clean, maintainable code. The rules include having only one level of indentation per method, avoiding else keywords, wrapping primitive types and strings that have behavior, using first class collections, limiting dots per line, avoiding abbreviations, keeping entities small, limiting instance variables, and avoiding getters and setters. Following these rules helps improve code quality by increasing readability and maintainability. The document encourages trying Object Calisthenics for a month to experience the benefits.
Report
Share
Object Calisthenics for Magento - MageTitans USA 2017
- 1. CLEAN CODE, OBJECT CALISTHENICS & BEST PRACTICES - IT'S TEXAS, BABY! by #MageTitansUSA @mhgontijo
- 2. Matheus Gontijo Y-E-E-A-A-H-H, we have a #Brazilian in the house, folks! So ware Engineer at Over 6 years of experience with Magento platform Speaker and attendee to conferences all over the world on twitter - ping me there ;- D Crimson Agility MCD & MCD+ @mhgontijo
- 3. What KILLS So ware Developers so badly?
- 6. uhmm... there are PLENTY some guys still writing code in our community like that...
- 7. Poorly written code equals... 💩💩💩 countless hours of energy being drained HUGE amount of time wasted === MONEY wasted ...it's unpleseant... it discourages the entire team to work with that mess
- 8. How can we improve our code? EXERCISING!
- 12. Object Calisthenics! btw has anybody ever heard about it?
- 13. Cal • is • then • ics /ˌkaləsˈTHeniks/ Greek word that means gymnastic exercises.
- 14. The concept was created by Jeff Bay in his book The ThoughtWorks Anthology A collection of exercises to focus on maintainability, readability, testability, and comprehensibility of your code.
- 15. PHP Community? Rafael Dohms - Keynode Speaker, Evangelist, and founder of PHPSP & PHPAmsterdam... which are awesome! Guilherme Blanco - Core Committer at Doctrine, Symfony and Zend Framework @rdohms @guilhermeblanco
- 16. THAT SHOULDN'T BE EXTREMELY... COMPLEX!!!
- 17. 9 simple rules to write code... WAY BETTER ✌
- 18. 9 simple rules advices to write code... WAY BETTER ✌
- 19. BUT don't follow them blindly.... It's NOT binary: RIGHT or WRONG There is not one-size-fits-all No Silver Bullet Don't take what I'm saying as absolute truth :- P the main goal is to challenge yourself... to make you RE-think the way you code...
- 20. 30 minutes only just going through quickly ; ) the examples are very simple just for the sake of easy understanding
- 21. #01 ADVICE Only One Level Of Indentation Per Method
- 24. Example: Let's say you are creating a process to update description
- 30. Benefits: Easy to understand! Single Responsibility Principle ("S" in S.O.L.I.D.) Encourages Re-use
- 31. #02 ADVICE Don't Use The ELSE Keyword
- 32. Example: Let's create a class in order to subscribe emails to a newsletter group called VIP.
- 33. Rules: It has to be a valid email. The email can not be registered again, if it already is. The email has to have a customer assigned the same email. The customer assigned to that email needs to be assigned to VIP Group also.
- 38. Benefits: Decreases Cyclomatic Complexity Prevents Code Duplication Legibility (Single Path)
- 45. #03 ADVICE Wrap All Primitives Types And Strings, If It Has Behavior
- 46. When? When your type needs validations, business rules or behaviors Email Zipcode Phone Number IP Address IBAN, ISBN URL List of status as Pending, Denied, Approved ...
- 47. Example: Let's say you are creating a class to send emails.
- 62. Benefits: Type Hinting Encapsulation of business rules Prevents Code Duplication Implements Value Objects of DDD
- 63. #04 ADVICE First Class Collections
- 66. Benefits: Single Responsibility Principle ("S" in S.O.L.I.D.) Implements SPL Interfaces Class for Filtering, Mapping, Ordering & other
- 67. #05 ADVICE One Dot Per Line
- 68. #05 ADVICE One Dot "->" Per Line
- 74. Law of Demeter
- 75. *** EXCEPT *** for Fluent Interfaces/Method Chaining since it was designed to work that way
- 85. #07 ADVICE Keep All Entities Small
- 87. Long files are hard to read... so... No methods with over 20 lines No namespaces over 15 files Class with 200 lines maximum Very challenging!
- 89. #08 ADVICE No Classes With More Than Two Five Instance Variables
- 91. Benefits: Higher Cohesion Lower Coupling Shorter Dependency list Maintainability
- 92. #09 ADVICE No Getters and Setters! just my favorite ❤ ❤ ❤
- 93. Example: Let's create a approval process for comments.
- 94. It's very important to the system to track the following: Previous Status New Status User that made the change Date
- 95. John is creating the a new approval record... Status: PENDING
- 96. Mary is creating the a new approval record... Status: PENDING ---> FIX_TYPO
- 97. David is creating the a new approval record... Status: FIX_TYPO ---> APPROVED
- 100. h4ck3r is creating the a new approval record... Status: APPROVED ---> APPROVED
- 101. h4ck3r is creating the a new approval record... Status: DENIED ---> DENIED
- 102. Solution? ENCAPSULATION! We have to HIDE business logic! BTW it's not something new... it's just encapsulation... basic concept of OOP
- 103. Now nobody will no longer be able to mess up the process ;- D
- 105. That's it! ✌ ✌ ✌ ✌
- 106. Recap 1. Only One Level Of Indentation Per Method 2. Don't Use The ELSE Keyword 3. Wrap All Primitives Types And Strings, If It Has Behavior 4. First Class Collections 5. One Dot "->" Per Line 6. Don't Abbreviate 7. Keep All Entities Small 8. No Classes With More Than Two Five Instance Variables 9. No Getters and Setters!
- 107. and the most important thing is...
- 108. You should give Object Calisthenics a try! Take a month and see how good that is!