Design Patterns in PHP Applications

A brief, subjective, opinionated and probably not precise review of design patterns used in PHP software. Presented at Inviqa Enlightening Lunch.

Transcript

1. DESIGN PATTERNS IN PHP APPLICATIONS INVIQA ENLIGHTENING LUNCH ARTURAS “2 SHEDS” SMORGUN
2. IN SOFTWARE ENGINEERING DESIGN PATTERN IS ! ! !
3. IN SOFTWARE ENGINEERING DESIGN PATTERN IS A REUSABLE SOLUTION ! !
4. IN SOFTWARE ENGINEERING DESIGN PATTERN IS A REUSABLE SOLUTION TO COMMON PROBLEM !
5. IN SOFTWARE ENGINEERING DESIGN PATTERN IS A REUSABLE SOLUTION TO COMMON PROBLEM WITHIN A GIVEN CONTEXT
6. MOTIVATION? REINVENTION OF SOLUTIONS; COMMUNICATION PROBLEMS.
7. CONCERNS? EASY TO OVER USE; WILL LEAD TO MORE MESS IF CHOSEN WRONG PATTERN.
8. DESIGN PATTERNS ELEMENTS OF REUSABLE OBJECT ORIENTED SOFTWARE
9. ! GANG OF FOUR ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, JOHN VLISSIDES.
10. 23 CLASSIC DESIGN PATTERNS
11. CREATIONAL PATTERNS FACTORY METHOD, SINGLETON, ABSTRACT FACTORY, BUILDER, PROTOTYPE.
12. STRUCTURAL PATTERNS ADAPTER, BRIDGE, COMPOSITE, DECORATOR, FACADE, FLYWEIGHT, PROXY.
13. BEHAVIOURAL PATTERNS CHAIN OF RESPONSIBILITY, COMMAND, INTERPRETER, ITERATOR, MEDIATOR, MEMENTO, OBSERVER, STATE, STRATEGY, TEMPLATE METHOD, VISITOR.
14. “EXTRAS” CONCURRENCY PATTERNS, ARCHITECTURAL PATTERNS, MANY MORE…
15. “GANG OF FOUR” FOR AVERAGE BEGINNER PHP DEVELOPER (ME, NOT LONG WHILE AGO)
16. FACTORY METHOD, SINGLETON, OBSERVER, ITERATOR.
17. POPULAR IN PHP DEPENDENCY INJECTION (STRUCTURAL), FRONT CONTROLLER (ARCHITECTURAL), MODEL VIEW CONTROLLER (ARCHITECTURAL), FACTORY (CREATIONAL), SINGLETON (CREATIONAL), OBSERVER (BEHAVIOURAL).
18. REVIEW OF PATTERNS
 IN PHP SOFTWARE. BRIEF, OPINIONATED, NOT PRECISE.
19. WHAT’S HOT? MODEL VIEW CONTROLLER, FRONT CONTROLLER, FACTORY METHOD, OBSERVER, REGISTRY, DECORATOR, VISITOR, …
20. MVC ARCHITECTURAL PATTERN. THREE TIER ARCHITECTURE TO RELATE USER INTERFACE TO UNDERLYING DATA MODELS.
21. TYPICAL MVC DIAGRAM
22. MODEL DATA AND BUSINESS LOGIC.
23. VIEW INTERFACE TO VIEW AND MODIFY DATA
24. CONTROLLER THIN MID LAYER BETWEEN MODEL AND VIEW: 1. ACCEPTS INPUT 2. EXECUTES COMMANDS ON MODEL 3. GENERATES OUTPUT
25. IMPLEMENTATION IN MAGENTO
26. IMPROVEMENTS? 1. MORE SEPARATED TIERS. 2. “THINNER” CONTROLLERS. 3. “DUMB” VIEWS.
27. FRONT CONTROLLER ARCHITECTURAL PATTERN. PROVIDES CENTRALISED ENTRY POINT FOR HANDLING REQUESTS. SPECIALISED CASE OF MEDIATOR PATTERN.
28. MEDIATOR PATTERN BEHAVIOURAL PATTERN. DEFINES AN OBJECT, WHICH DECIDES HOW A SET OF OBJECTS INTERACTS.
29. TYPICAL MEDIATOR DIAGRAM
30. MEDIATOR DEFINES AN INTERFACE FOR COMMUNICATING WITH COLLEAGUE OBJECTS.
31. CONCRETE MEDIATOR IMPLEMENT COOPERATIVE BEHAVIOUR; KNOWS AND MAINTAINS IT’S COLLEAGUES.
32. C0LLEAGUE KNOWS IT’S MEDIATOR; COMMUNICATES WITH MEDIATOR INSTEAD OF OTHER COLLEAGUES.
33. IMPLEMENTATION IN OXID
34. SINGLETON CREATIONAL (ANTI)PATTERN. ENSURES A CLASS HAS ONLY ONE INSTANCE. PROVIDES A GLOBAL POINT OF ACCESS TO IT. AVOID AT ANY COST!
35. WHERE IT’S USED? MAGENTO, SILVERSTRIPE, PRESTASHOP, OXID.
36. WHY IT’S SO BAD? GLOBAL INSTANCE - HIDING DEPENDENCIES; USUALLY LEADS TO TIGHT COUPLING; USUALLY CARRIES AROUND GLOBAL STATE; STATIC CALL - HARD TO MOCK.
37. ALTERNATIVES? USE A FACTORY INSTEAD; INSTANTIATE AT THE TOP OF APP PASS TO COMPONENTS VIA DEPENDENCY INJECTION.
38. REGISTRY STRUCTURAL PATTERN (NOT GOF). A CONTAINER OF SHARED OBJECTS.
39. DANGEROUS? OFTEN USED WITH STATIC CALLS. WHEN ABUSED LEADS TO HIDDEN DEPENDENCIES.
40. EXAMPLE FROM OPENCART
41. EXAMPLE FROM SYLIUS
42. HOW TO IMPROVE? BEING DISCIPLINED ABOUT WHAT TO STORE IN REGISTRY, NOT USING STATIC CALLS.
43. DECORATOR STRUCTURAL PATTERN. ATTACH ADDITIONAL RESPONSIBILITIES TO AN OBJECT DYNAMICALLY.
44. TYPICAL DECORATOR DIAGRAM
45. COMPONENT DEFINES AN INTERFACE FOR OBJECT THAT CAN HAVE RESPONSIBILITIES ADDED TO THEM DYNAMICALLY.
46. CONCRETE COMPONENT DEFINES AN OBJECT TO WHICH ADDITIONAL RESPONSIBILITIES CAN BE ATTACHED.
47. DECORATOR MAINTAINS A REFERENCE TO A COMPONENT OBJECT; DEFINES AN INTERFACE THAT CONFORMS TO COMPONENT’S INTERFACE.
48. CONCRETE DECORATOR ADDS RESPONSIBILITIES TO THE COMPONENT.
49. EXAMPLE FROM SILVERSTRIPE
50. ALTERNATIVE? STRATEGY DESIGN PATTERN
51. STRATEGY BEHAVIOURAL PATTERN. DEFINES A FAMILY OF ALGORITHMS AND MAKE THEM INTERCHANGEABLE.
52. TYPICAL STRATEGY DIAGRAM
53. STRATEGY DECLARES AN INTERFACE COMMON TO ALL SUPPORTED ALGORITHMS; IS USED BY CONTEXT TO CALL ALGORITHM.
54. CONCRETE STRATEGY IMPLEMENTS THE ALGORITHM USING STRATEGY INTERFACE.
55. CONTEXT IS CONFIGURED WITH A CONCRETE STRATEGY OBJECT; MAINTAINS A REFERENCE TO A STRATEGY OBJECT; DEFINES INTERFACE FOR STRATEGY TO ACCESS ITS DATA (OPTIONAL).
56. DIFFERENCES FROM DECORATOR SWITCHES ENTIRE ALGORITHM RATHER THAN WRAPS IT UP.
57. COMMON ANTIPATTERNS STATIC CALLS, EXCESSIVE USE OF GLOBAL CONSTANTS, EXCESSIVE USE OF MAGIC, SINGLETONS, GOD CLASSES.
58. WHAT’S MY POINT?
59. DESIGN PATTERNS ARE NOT THAT WIDE SPREAD. MANY FRAMEWORKS MAKE USE OF LIMITED SUBSET OF THEM. THERE ARE ALSO N WAYS TO IMPLEMENT DESIGN PATTERN.
60. THERE IS ALTERNATIVE TO EVERYTHING. BE AWARE OF YOUR OPTIONS AND KNOW WHERE TO LOOK IT UP WHEN NEEDED.
61. KNOWING ANTIPATTERNS IS IMPORTANT TO RAISE AWARENESS AND NOT TO FALL INTO THE SAME TRAP AS PROCEEDERS DID.
62. INSTEAD OF QUESTIONS: GO AND DISCUSS WITHIN YOUR TEAM.
63. THANK YOU.