Code readability: Session 7 (ver. 2, En)

Session 7: Dependency II

Session 1: Introduction and Principles
- https://speakerdeck.com/munetoshi/code-readability-session-1-ver-2-en

Session 2: Naming
- https://speakerdeck.com/munetoshi/code-readability-session-2-ver-2-en

Session 3: Comments
- https://speakerdeck.com/munetoshi/code-readability-session-3-ver-2-en

Session 4: State
- https://speakerdeck.com/munetoshi/code-readability-session-4-ver-2-en

Session 5: Function
- https://speakerdeck.com/munetoshi/code-readability-session-5-ver-2-en

Session 6: Dependency I
- https://speakerdeck.com/munetoshi/code-readability-session-6-ver-2-en

Session 7: Dependency II
- https://speakerdeck.com/munetoshi/code-readability-session-7-ver-2-en

Session 8: Review
- https://speakerdeck.com/munetoshi/code-readability-session-8-ver-2-en

Previous version: https://speakerdeck.com/munetoshi/code-readability

For the Japanese version, refer to https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571

© 2019-2023 Munetoshi Ishikawa, supported by LINE corporation

Transcript

1. Code←readability←session←7 Dependency ‐‐
2. Brushup: Coupling Use weaker coupling - Stamp coupling or data coupling preferred Coupling to be aware of: - Content coupling: Depends on internal working - Common/external coupling: Shares mutable global data - Control coupling: Determines "what to do" by arguments
3. Contents of this lecture - Introduction and Principles - Natural language: Naming, Comments - Inner type structure: State, Function - Inter type structure: Dependency I, Dependency II - Follow-up: Review Dependency > Introduction
4. Contents of Dependency I & II Dependency I: - Coupling Dependency II: - Direction - Redundancy - Explicitness Dependency > Direction
5. Dependency direction Keep dependencies acyclic as far as possible Class A Class C Class B cyclic Class A Class C Class B acyclic Dependency > Direction
6. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple - mutable → immutable - unstable → stable - algorithm → data model Dependency > Direction
7. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple Dependency > Direction
8. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple Dependency > Direction > Caller to callee
9. Caller and callee: Bad example 1/2 class MediaViewPresenter { fun getVideoUri(): Uri = ... fun playVideo() { videoPlayerView.play(this) ... class VideoPlayerView { fun play(presenter: MediaViewPresenter) { val uri = presenter.getVideoUri() Dependency > Direction > Caller to callee
10. Caller and callee: Bad example 2/2 MediaViewPresenter fun getVideoUri VideoPlayerView fun play calls play calls getVideoUri Dependency > Direction > Caller to callee
11. Caller and callee: Bad points Difficult to understand the behavior The call sequence of playVideo is complex Large impact on modification Changes in MediaViewPresenter affect VideoPlayerView Hard to write tests Mock object of VideoPlayerView will be complicated Dependency > Direction > Caller to callee
12. Caller and callee: How to fix Remove unnecessary callback - Pass values as arguments - Extract small classes Dependency > Direction > Caller to callee
13. Caller and callee: How to fix Remove unnecessary callback - Pass values as arguments - Extract small classes Dependency > Direction > Caller to callee
14. Pass values as arguments class MediaViewPresenter { fun getVideoUri(): Uri = ... fun playVideo() { videoPlayerView.play(this) ... class VideoPlayerView { fun play(presenter: MediaViewPresenter) { val uri = presenter.getVideoUri() Dependency > Direction > Caller to callee
15. Pass values as arguments class MediaViewPresenter { fun getVideoUri(): Uri = ... fun playVideo() { videoPlayerView.play(getVideoUri()) ... class VideoPlayerView { fun play(videoUri: Uri) { ... Dependency > Direction > Caller to callee
16. Caller and callee: How to fix Remove unnecessary callback - Pass values as arguments - Extract small classes Dependency > Direction > Caller to callee
17. Extract small classes Cannot pass value directly for asynchronous evaluation Extract depended logic as a class Dependency > Direction > Caller to callee
18. Extract small classes: Step 1 Create a named class for the callback MediaViewPresenter VideoPlayerView VideoUriProvider fun getVideoUri Dependency > Direction > Caller to callee
19. Extract small classes: Step 2 Move the named class out of the outer class MediaViewPresenter VideoPlayerView VideoUriProvider fun getVideoUri Dependency > Direction > Caller to callee
20. Caller and callee: How to fix Remove unnecessary callback - Pass values as arguments - Extract small classes Dependency > Direction > Caller to callee
21. Caller and callee: Exception Dependency on a caller may be acceptable for some cases - Asynchronous call: thread, event listener - Higher order function as a utility: List.forEach Dependency > Direction > Caller to callee
22. Mitigating asynchronous calls Limit purpose/lifecycle/scope of a callback - promise pattern, future object Use language features or libraries for asynchronous calls - coroutine, actor, async/await Dependency > Direction > Caller to callee
23. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple Dependency > Direction > Concrete to abstract
24. Concrete and abstract Do not depend on inheritances = Do not check type of this or self Dependency > Direction > Concrete to abstract
25. Concrete and abstract: Bad example open class IntList { fun addElement(value: Int) { if (this is ArrayIntList) { ... } else { ... ... class ArrayIntList: IntList() { ... Dependency > Direction > Concrete to abstract
26. Concrete and abstract: Bad points Ambiguous scope of the responsibility Not robust against modification - For inheritance specification change - To add a new inheritance Dependency > Direction > Concrete to abstract
27. Concrete and abstract: How to fix Remove downcast with overriding open class IntList { open fun addElement(value: Int) { ... class ArrayIntList: IntList() { override fun addElement(value: Int) { ... Dependency > Direction > Concrete to abstract
28. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple Dependency > Direction > Complex to simple
29. Complex and simple: Bad example class UserData( val userId: UserId, ... ) class UserDataRequester { fun obtainFromServer(): UserData { ... Dependency > Direction > Complex to simple
30. Complex and simple: Bad example class UserData( val userId: UserId, ... val requester: UserDataRequester ) class UserDataRequester { fun obtainFromServer(): UserData { ... Dependency > Direction > Complex to simple
31. Complex and simple: Bad points Hard to manage scope/lifecycle/references of complex code - Simple: Scope/lifecycle can be _small to large - Complex: Scope/lifecycle must be managed strictly Dependency on complex code may cause: - Resource leaks - implicit preconditions for simple code Dependency > Direction > Complex to simple
32. Complex and simple: How to fix Just remove dependency of "simple to complex" - Pass a complex class instance directly if required class UserData( val userId: UserId, ... ) Dependency > Direction > Complex to simple
33. Complex and simple: Exceptions It is sometimes necessary to depend on complex types - Mediator pattern - Adapter/facade - Data binder Limit objective/scope as far as possible Dependency > Direction > Complex to simple
34. Preferred dependency direction - caller → callee - concrete → abstract - complex → simple Dependency > Direction > Summary
35. Dependency direction: Summary Maintain acyclic dependency - caller → callee - complex, concrete, mutable → simple, abstract, immutable Exceptions: asynchronous calls, mediator patterns, etc. Limit the objective/scope, even for the exceptions Dependency > Direction > Summary
36. Contents of Dependency I & II Dependency I: - Coupling Dependency II: - Direction - Redundancy - Explicitness Dependency > Redundancy
37. Redundant dependency Cascaded dependency - Nested & indirect dependency Redundant dependency set - N:M dependency Dependency > Redundancy
38. Redundant dependency Cascaded dependency - Nested & indirect dependency Redundant dependency set - N:M dependency Dependency > Redundancy
39. Cascaded dependency Do not depend on unrelated code only for getting a reference MessageTextPresenter TimestampPresenter has instance (only for MessageDataProvider) MessageDataProvider has instance depends indirectly Dependency > Redundancy > Cascaded dependency
40. Cascaded dependency: Bad example class TimestampPresenter { val dataProvider: MessageDataProvider = ... fun invalidateViews() { // Update timestamp by `dataProvider` ... class MessageTextPresenter { val timestampPresenter: TimestampPresenter = ... fun invalidateViews() { val messageData = timestampPresenter.dataProvider... // Update message text view by `messageData` Dependency > Redundancy > Cascaded dependency
41. Cascaded dependency: Bad points Unnecessary dependency MessageTextPresenter is unrelated with TimestampPresenter Indirect dependency MessageTextPresenter does not have MessageDataProvider directly Dependency > Redundancy > Cascaded dependency
42. Cascaded dependency: How to fix Flatten nested dependencies by means of direct dependency MessageTextPresenter TimestampPresenter MessageDataProvider has instance Dependency > Redundancy > Cascaded dependency
43. Cascaded dependency: Fixed code example class TimestampPresenter { val dataProvider: MessageDataProvider = ... fun invalidateViews() { // Update timestamp by `dataProvider` ... class MessageTextPresenter { val dataProvider: MessageDataProvider = ... fun invalidateViews() { // Update message text view by `dataProvider` Dependency > Redundancy > Cascaded dependency
44. Redundant dependency Cascaded dependency - Nested & indirect dependency Redundant dependency set - N:M dependency Dependency > Redundancy > Dependency set
45. Redundant dependency set Avoid duplication of "depending class set" MessageTextPresenter TimestampPresenter LocalMessageDataProvider RemoteMessageDataProvider Dependency > Redundancy > Dependency set
46. Redundant dependency set: Bad points Fragile for modification - When a new depending/depended class is added - Because of code duplication Dependency > Redundancy > Dependency set
47. Redundant dependency set: How to fix Create an intermediate layer to consolidate the dependency set MessageTextPresenter TimestampPresenter LocalMessageDataProvider RemoteMessageDataProvider MessageDataProvider Dependency > Redundancy > Dependency set
48. Redundant dependency set: Note Do not create a layer if you do not need it now Keep "YAGNI" and "KISS" in mind Do not provide access to a hidden layer Never make a public property serverMessageDataProvider in MessageDataProvider Dependency > Redundancy > Dependency set
49. Redundant dependency set: Summary - Do not depend on unrelated code only for getting a reference - Create an intermediate layer to consolidate the dependency set Dependency > Redundancy > Summary
50. Contents of Dependency I & II Dependency I: - Coupling Dependency II: - Direction - Redundancy - Explicitness Dependency > Explicitness
51. Implicit dependency 1/3 Dependency that is not discoverable only by class definitions interface Interface class Implementation : Interface class Caller(val interface: Interface) Caller may be affected by modification in Implementation Caller(Implementation()) Dependency > Explicitness
52. Implicit dependency 2/3 Not discoverable by class diagram Caller Interface Implementation has instance inherits Dependency > Explicitness
53. Implicit dependency 2/3 Use explicit dependencies instead of implicit dependencies To clarify affected scope of modification Different from "weak coupling" - Trying to use weak coupling may cause implicit dependency Dependency > Explicitness
54. Implicit dependency: Example - Unnecessary abstraction - Implicit domain of variable Dependency > Explicitness
55. Implicit dependency: Example - Unnecessary abstraction - Implicit domain of variable Dependency > Explicitness > Unnecessary abstraction
56. Unnecessary abstraction Caller may depend on a child class implicitly ProfilePresenter MessagePresenter StringProvider ProfileDataRepository MessageDataRepository Dependency > Explicitness > Unnecessary abstraction
57. Unnecessary abstraction: Bad example interface StringProvider { fun queryString(id: Int): String } class ProfileDataRepository : StringProvider { /** Returns user name of the given [userId] */ override fun queryString(userId: Int): String = ... } class ProfilePresenter(val nameProvider: StringProvider, ...) { fun updateProfileView(userId: Int) { userNameView.text = nameProvider.queryString(userId) ... Dependency > Explicitness > Unnecessary abstraction
58. Unnecessary abstraction: Bad points Time-consuming to track the call sequence Requires checking the constructor caller A wrong instance may be passed Compiles even if MessageDataRepository is passed Dependency > Explicitness > Unnecessary abstraction
59. Unnecessary abstraction: How to fix Remove unnecessary subtyping Use child class directly with removing the parent/interface ProfilePresenter MessagePresenter ProfileDataRepository MessageDataRepository Dependency > Explicitness > Unnecessary abstraction
60. Unnecessary abstraction: Fixed code example class ProfileDataRepository { fun queryUserName(userId: Int): String = ... } class ProfilePresenter(val repository: ProfileDataRepository, ...) { fun updateProfileView(userId: Int) { userNameView.text = repository.queryUserName(userId) ... Dependency > Explicitness > Unnecessary abstraction
61. Unnecessary abstraction: Note 1/2 Clarify objective of subtyping - Polymorphism - Sum type: sealed class - Dependency inversion, implement separation: module/library Dependency > Explicitness > Unnecessary abstraction
62. Unnecessary abstraction: Note 2/2 Avoid using subtyping only to make code common - Consider using aggregation or composition instead Consider using another method to achieve polymorphism - Parametric: generics, etc. - Adhoc: overloading, type-class, etc. Dependency > Explicitness > Unnecessary abstraction
63. Implicit dependency: Example - Unnecessary abstraction - Implicit domain of variable Dependency > Explicitness > Implicit domain of variable
64. Implicit domain of variable: Bad example Question: What is wrong with the following code? fun setViewBackgroundColor(colorString: String) { val colorCode = when(colorString) { "red" -> 0xFF0000 "green" -> 0x00FF00 else -> 0x000000 } view.setBackgroundColor(colorCode) } Dependency > Explicitness > Implicit domain of variable
65. Implicit domain of variable: Bad points An implicit constraint between the caller and callee Need to know which value is accepted "blue", "RED", "FF0000" are invalid Fragile for modification Need to update the caller when a color is added/removed Dependency > Explicitness > Implicit domain of variable
66. Implicit domain of variable: How to fix Create a model type representing the domain enum class BackgroundColor(val colorCode: Int) { RED(0xFF0000), GREEN(0x00FF00) } fun setViewBackgroundColor(color: BackgroundColor) { view.setBackgroundColor(color.colorCode) } Dependency > Explicitness > Implicit domain of variable
67. Dependency explicitness: Summary Use explicit dependency - Make dependency visible on class definition/diagram - Do not be confused with weak coupling To make dependency explicit - Remove unnecessary abstraction layer - Create a model type representing the domain Dependency > Explicitness > Summary
68. Summary ɹ Coupling: Mitigate content/common/external/control coupling Direction: Make dependency acyclic or encapsulate the cycle Redundancy: Avoid duplication of dependency Explicitness: Make dependency visible on the definition/diagram Dependency > Summary