2. WTF?
● code is hard to understand, test and
maintain
● OO will save us!
● it's hard the transaction of paradigms
Procedural --- to --- OOP
● Qualities matters:
○ cohesion
○ loose coupling
○ no redundancy
○ encapsulation
○ testability
○ readability
3. so what is it about?
It's an exercise, a practice to help you to write
good oriented-object code!
4. The RULES
#1 One level of indentation per method
#2 Don't use ELSE keyword
#3 Wrap all primitives and String
#4 First class collections
#5 One dot per file
#6 Don't abbreviate
#7 Keep all entities small
#8 No classes with more than two instances
variable
#9 No getters/setters/properties
7. #RULE3
You shall encapsulate the primitives types
not totally applicable in PHP because of performance issues
but... we can do this with other types...
9. #RULE 5
You shall use one dot per file, so you know
each object has the responsible
not totally applicable in PHP...
... but nested calls
● show some problems of encapsulation
make harder to debug
...
● we can use...
in chain of get and setters
in chain of objects with a fluent interface
10. #RULE 6
You must not abbreviate
why I should abbreviate?
● because I use the name several times...
● .... maybe your method is to heavily and you should remove
duplication
● or because the names are too long...
● ... maybe you are misplacing responsibilities or there is a missing
class...
Avoid also duplicate of words...
11. #RULE 7
Keep your entity classes smaller!
50 rows by class
10 classes by package...
maybe 100 rows by class and 15 by package it's also OK!
12. #RULE 8
Class shall have less than 2 instance variables
Yep quite hard this... but let's try...
with this we can decomposition, we can separate the concerns...
maybe 5 variables it's also okay don't you think?
13. #RULE 9
You shall not have getter and setters
WTF?
Yeah, PHP it's not possible apply that :|
BUT...
If we apply the #RULE 8 we may get this!