Slide 1
Slide 1 text
Components Reconsidered
by itosho / Connehito Inc.
CakeFest 2021 Virtual🍰
Slide 2
Slide 2 text
Hello, everyone!
Slide 3
Slide 3 text
About Me
Sho ITO / @itosho
- Japanese, live in Tokyo
- Like Basketball🏀, Football⚽
- Backend Engineer, CakePHP Contributor
- My OSS: https://github.com/itosho/easy-query
- CTO, Connehito Inc.
- We use CakePHP in our backend system
Slide 4
Slide 4 text
About Our Company
Slide 5
Slide 5 text
Creating services that people cannot live without
Connehito uses the power of technology to provide support to
families in their daily decision makings about their matter
Slide 6
Slide 6 text
Brand that supports mothers' each step
Business Lineup
Slide 7
Slide 7 text
No.1 app for mothers in Japan!
One third of mothers in Japan are using mamari
Communication amongst users about their worries and
experiences about childbearing and childcare
Q&A Community App
Delivery of useful articles about childbearing and childcare. Many
articles are supervised by experts
Web Media
A subscription service provides more useful functions
e.g. medical telephone consultation, premium search functions
Mamari Premium
Slide 8
Slide 8 text
Have you ever used Components?
Slide 9
Slide 9 text
When do you use Components?
Slide 10
Slide 10 text
Today’s Topics
Seeking better software through reconsideration of Components
- 1. What are Components?
- General use case / Other use case
- 2. Other approaches
- Traits / Dependency Injection
- 3. When to use Components
- And when not to
Slide 11
Slide 11 text
Appendix
- Code examples
- https://github.com/itosho/x-cakefest21
- PHP8.0, CakePHP4.2
Slide 12
Slide 12 text
1. What are Components?
Slide 13
Slide 13 text
In short
- Packages of logic that are shared between controller classes
- Core Components are …
- Flash Component
- FormProtection Component
- Paginator Component
- Request Handler Component
- Auth Compoent
- Security Component
Slide 14
Slide 14 text
Basic Usage of a Paginator Component
Slide 15
Slide 15 text
General use case
Slide 16
Slide 16 text
Component as a shared logic package
- When we have a logic that is used by many controllers
👇
- Creating a Component and move the logic to the Component
👇
- Keep controller code clean and allow us to reuse code
- Run a unit testing focused on that logic by separating the logic from controllers
Slide 17
Slide 17 text
Component as a shared logic package
Slide 18
Slide 18 text
Unit testing of Component as a shared logic package
Slide 19
Slide 19 text
Other use case
Slide 20
Slide 20 text
Component as a service-like class
- When you call an external Web API from a controller
- e.g. Qiita API which Japanese weblog service for engineers
👇
- Creating a HTTP Client and a Component
- This component is a wrapper for the HTTP client and the controller
👇
- Remove the business logic from the controller
- Making the HTTP client and the controller independent eases a unit testing
Slide 21
Slide 21 text
A HTTP Client and its unit testing
Slide 22
Slide 22 text
Component as a service-like class
Slide 23
Slide 23 text
Unit testing of Component as a service-like class
Slide 24
Slide 24 text
2. Other approaches
Slide 25
Slide 25 text
Summary so far
- Two Components use cases
- As a shared logic package
- As a service-like class
Slide 26
Slide 26 text
Summary so far
- Two Components use cases
- As a shared logic package
- As a service-like class
Slide 27
Slide 27 text
As a shared logic package Pattern
- Clean the controller code and reuse it (Repeated)
- Expand the controller's behavior in horizontal direction
Slide 28
Slide 28 text
Can we do something similar to it with Traits?
Slide 29
Slide 29 text
What are Traits?
- A mechanism for code reuse in single inheritance languages
- Enables horizontal composition of behavior
- It is not possible to instantiate a Trait on its own
Parent Class
Child Class A Child Class B
Trait A Trait B
Slide 30
Slide 30 text
A Trait Pattern
Slide 31
Slide 31 text
We did it!
Slide 32
Slide 32 text
Summary so far
- Two Components use cases
- As a shared logic package
- As a service-like class
Slide 33
Slide 33 text
As a service-like class
- Remove the business logic from the controller (Repeated)
- Make a loose coupling between the HTTP client and the controller.
Slide 34
Slide 34 text
Can we do something similar to it with DI?
Slide 35
Slide 35 text
What are DI and DI container?
- A technique for making our code loose coupled
- By injecting an object from the outside
- Make testing and managing our software easier
- Depend on abstractions, not on concretions
- DI container is a box that manages DI objects in one place
Caller (Client)
Object
Concrete
Object
Abstract
Object
Slide 36
Slide 36 text
A HTTP Client using an interface
Slide 37
Slide 37 text
A DI Pattern
Slide 38
Slide 38 text
Unit testing of a DI Pattern
Slide 39
Slide 39 text
We did it!
Slide 40
Slide 40 text
3. When to use Components
Slide 41
Slide 41 text
Summary so far
- Two Components use cases
- As a shared logic package
- As a service-like class
- Two Other approaches
- As a shared logic package: Components or Traits
- As a service-like class: Components or Dependency Injection
Slide 42
Slide 42 text
Whether you should use Components or Traits?
Slide 43
Slide 43 text
When to use Traits
- Better to use Traits for a horizontal shared logic
- In many use cases, Traits are usually sufficient
- Originally, business logic should not be written in Components
- Better move the previous method to the model layer
- If the logic is about Requests or Responses, Middleware might be able to replace it
Slide 44
Slide 44 text
When to use Components
- Better to use Components for a more three-dimensional shared logic
Slide 45
Slide 45 text
When to use Components
Slide 46
Slide 46 text
- Augment the request life-cycle.
- initialize() 👉 beforeFilter(Component) 👉 beforeFilter(Controller) 👉 startup() 👉 …
Component Callbacks
Inheritance (y)
Traits (x)
Components (z)
Slide 47
Slide 47 text
Whether you should use Components or DI?
Slide 48
Slide 48 text
When to use DI
- Better to use DI for a service class that calls a HTTP client
- Looser coupling between modules than the Service Locator pattern(=Components)
- 🙋 This doesn’t mean denying Components
- Since Cake3, the change to the policy of creating a local registry has been better!
Slide 49
Slide 49 text
Compare with unit testing(Repeated)
Slide 50
Slide 50 text
Components inferior to Traits and DI?
Slide 51
Slide 51 text
Of course not
Slide 52
Slide 52 text
What is in Components and not in Traits or DI?
Slide 53
Slide 53 text
It’s “Convention”
Slide 54
Slide 54 text
Convention over configuration
- Convention is very effective in team development
- Get a unified developer experience
- Traits and DI are more challenging to maintain consistency
- In other words, a skilled team can use the best of Traits and DI
Slide 55
Slide 55 text
Summary
Slide 56
Slide 56 text
- When to use Components and when not to
My conclusion
Team / Case Shared logic
(Horizontal)
Shared logic
(Three-dimensional)
Service-like class
(Using HTTP Clients)
Skilled team Traits Compoents DI
Not skilled team Components Components Components
Slide 57
Slide 57 text
- When to use Components and when not to
- What do you think?
My Conclusion
Team / Case Shared logic
(Horizontal)
Shared logic
(Three-dimensional)
Service-like class
(Using HTTP Clients)
Skilled team Traits Compoents DI
Not skilled team Components Components Components
Slide 58
Slide 58 text
Our journey to seek better software will continue
Slide 59
Slide 59 text
Thank you!