Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Decoupling Packages From Your Framework

Adam Wathan
November 08, 2014

Decoupling Packages From Your Framework

It's really fun to build a package that adds some awesome functionality to your favourite framework. If you're not careful however, you can end up releasing something that nobody could use outside of Framework-X no matter how hard they try.

In this talk, I'll walkthrough building a framework agnostic package. You'll learn about important OO design principles like dependency injection, interfaces, and encapsulation, and see how we can integrate our package with a modern framework like Laravel, or the messiest legacy codebase you've ever seen.

Adam Wathan

November 08, 2014
Tweet

More Decks by Adam Wathan

Other Decks in Programming

Transcript

  1. DECOUPLING PACKAGES
    FROM YOUR FRAMEWORK
    @ADAMWATHAN

    View Slide

  2. @ADAMWATHAN
    ▸ Software developer
    ▸ Host of Full Stack Radio
    ▸ Former Audio engineer
    ▸ Competitive powerlifter

    View Slide

  3. @ADAMWATHAN
    ▸ Software developer
    ▸ Host of Full Stack Radio
    ▸ Former Audio engineer
    ▸ Competitive powerlifter
    ▸ ...Batman?

    View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. 42,288
    PACKAGES

    View Slide

  8. 413,057,365
    PACKAGES INSTALLED

    View Slide

  9. View Slide

  10. An example...

    View Slide

  11. FLUENT FORM BUILDER

    View Slide

  12. 1. REPOPULATE FORM WITH OLD INPUT IF SUBMISSION FAILS

    View Slide

  13. Ditch this...

    View Slide

  14. ...for just this:

    View Slide

  15. 2. ABLE TO RETRIEVE ERROR MESSAGES FOR EACH ELEMENT

    View Slide

  16. Something like this...

    View Slide

  17. #1: RETRIEVING OLD INPUT

    View Slide

  18. Probably this sort of thing...

    View Slide

  19. In Laravel...

    View Slide

  20. In Laravel...

    View Slide

  21. So maybe...

    View Slide

  22. Nope.

    View Slide

  23. Composer.json...

    View Slide

  24. The whole truth...

    View Slide

  25. What about...

    View Slide

  26. No dependencies
    !==
    NO COUPLING

    View Slide

  27. So what's the
    answer?

    View Slide

  28. Dependency
    INJECTION

    View Slide

  29. Dependency injection is a software design pattern that
    implements inversion of control and allows a program
    design to follow the dependency inversion principle. 1
    1 http://en.wikipedia.org/wiki/Dependency_injection

    View Slide

  30. ...Come again?

    View Slide

  31. INSTEAD OF AN OBJECT GETTING
    IT'S OWN DEPENDENCIES,
    WE SHOULD GIVE THEM TO THE
    OBJECT OURSELVES.

    View Slide

  32. So this...

    View Slide

  33. Becomes this...

    View Slide

  34. THIS IS BETTER BUT...

    View Slide

  35. We're still coupled...

    View Slide

  36. DEPEND ON INTERFACES
    not implementations

    View Slide

  37. Something like...

    View Slide

  38. INTERFACES 101

    View Slide

  39. INTERFACES 101
    ▸ Like a contract

    View Slide

  40. INTERFACES 101
    ▸ Like a contract
    ▸ Describes public API of a role

    View Slide

  41. INTERFACES 101
    ▸ Like a contract
    ▸ Describes public API of a role
    ▸ Does not provide any implementation

    View Slide

  42. INTERFACES 101
    ▸ Like a contract
    ▸ Describes public API of a role
    ▸ Does not provide any implementation
    ▸ Great as documentation in a package

    View Slide

  43. An implementation...

    View Slide

  44. Now instead of this...

    View Slide

  45. ...we can do this:

    View Slide

  46. What about
    OTHER
    frameworks?

    View Slide

  47. What about
    NON-FRAMEWORK
    applications?

    View Slide

  48. Aww yeah

    View Slide

  49. #2: ERROR MESSAGES

    View Slide

  50. Something like this would be cool...

    View Slide

  51. So we need these badboys...

    View Slide

  52. Could do this...

    View Slide

  53. Let's add it to the interface...

    View Slide

  54. ...and the implementation:

    View Slide

  55. Looks good right?

    View Slide

  56. Why a
    SESSION?

    View Slide

  57. Identify the right
    ABSTRACTIONS

    View Slide

  58. 1.
    Somewhere to get
    OLD INPUT

    View Slide

  59. 2.
    Somewhere to get
    ERRORS

    View Slide

  60. Somewhere to get old input...

    View Slide

  61. Somewhere to get errors...

    View Slide

  62. Somewhere to get old input...

    View Slide

  63. Somewhere to get errors...

    View Slide

  64. Updated Form Builder...

    View Slide

  65. Laravel Old Input...

    View Slide

  66. Laravel Error Store...

    View Slide

  67. Legacy Old Input...

    View Slide

  68. Legacy Error Store...

    View Slide

  69. Symfony Old Input...

    View Slide

  70. Focus on
    ONE JOB

    View Slide

  71. Bootstrap prototype...

    View Slide

  72. Bootstrap prototype...

    View Slide

  73. Bootstrap boilerplate...

    View Slide

  74. ...reduced to this:

    View Slide

  75. Optimize for
    COMPOSABILITY

    View Slide

  76. BootForms dependencies...

    View Slide

  77. Composabilitize!

    View Slide

  78. View Slide

  79. YOU DON'T HAVE TO SUPPORT EVERY FRAMEWORK OUT OF THE BOX...
    JUST DON'T GET IN THE WAY.

    View Slide

  80. Why?

    View Slide

  81. ENCOURAGES COMMUNITY COLLABORATION

    View Slide

  82. IT'S JUST GOOD CODE.

    View Slide

  83. @ADAMWATHAN
    ADAMWATHAN.ME
    FULLSTACKRADIO.COM
    JOIND.IN/12711

    View Slide