Go Component Design: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Tag: Manual revert
 
(16 intermediate revisions by the same user not shown)
Line 1: Line 1:
=External=
*  [https://www.youtube.com/watch?v=PTE4VJIdHPg Peter Bourgon - Best Practices for Industrial Programming]
=Internal=
=Internal=
* [[Go Engineering#Subjects|Go Engineering]]
* [[Go Engineering#Subjects|Go Engineering]]
=Overview=
=Explicit Component Dependencies=


=Organizatorium=
... and the avoidance of inversion of control (?):


Prefer this style:
Prefer this style:
Line 19: Line 25:
}
}
</syntaxhighlight>
</syntaxhighlight>
We get explicitness: each component is constructed in dependency order, with errors handled in-line as they occur. Each constructor enumerates its dependencies as parameters, allowing new code readers to easily build the mental model of the relationship between the components, and nothing is obscured behind layers of indirection. If a refactoring requires a component to acquire a new dependency, it simply needs to be added to the relevant constructor. The next compile will trigger errors along the dependency lists, the and the diff result in the PR will clearly show the flow of dependencies throughout the program.
We get explicitness: each component is constructed in dependency order, with errors handled in-line as they occur. Each constructor enumerates its dependencies as parameters, allowing new code readers to easily build the mental model of the relationship between the components, and nothing is obscured behind layers of indirection. If a refactoring requires a component to acquire a new dependency, it simply needs to be added to the relevant constructor. The next compile will trigger errors along the dependency lists, the and the diff result in the PR will clearly show the flow of dependencies throughout the program. This brings the failure detection in miswired components at compile-time, rather than deferring to runtime.
 
A Go program should have little to no <span id='Package_Global_State'></span>[[Go_Packages#Package_Global_State|package global state]] and instead it should enumerate dependencies through constructors.


More details here: [https://www.youtube.com/watch?v=PTE4VJIdHPg Peter Bourgon - Best Practices for Industrial Programming]
More details here: [https://www.youtube.com/watch?v=PTE4VJIdHPg Peter Bourgon - Best Practices for Industrial Programming]
=Organizatorium=
<font color=darkkhaki>
* Dependency injection in Go: https://medium.com/@MTrax/golang-the-ultimate-guide-to-dependency-injection-4556b97f9cbd
* Dependency injection in Go: https://medium.com/@samims/understanding-dependency-injection-and-interface-in-golang-2d1a326033e0
</font>

Latest revision as of 00:00, 13 February 2024

External

Internal

Overview

Explicit Component Dependencies

... and the avoidance of inversion of control (?):

Prefer this style:

func main() {
  cfg := GetConfig()
  db, err := ConnectDatabase(cfg.URN)
  if err != nil {
    panic(err)
  }
  repo := NewPersonRepository(db)
  service := NewPersonService(cfg.AccessToken, repo)
  server := NewServer(cfg.ListenAddr, service)
  server.Run()
}

We get explicitness: each component is constructed in dependency order, with errors handled in-line as they occur. Each constructor enumerates its dependencies as parameters, allowing new code readers to easily build the mental model of the relationship between the components, and nothing is obscured behind layers of indirection. If a refactoring requires a component to acquire a new dependency, it simply needs to be added to the relevant constructor. The next compile will trigger errors along the dependency lists, the and the diff result in the PR will clearly show the flow of dependencies throughout the program. This brings the failure detection in miswired components at compile-time, rather than deferring to runtime.

A Go program should have little to no package global state and instead it should enumerate dependencies through constructors.

More details here: Peter Bourgon - Best Practices for Industrial Programming

Organizatorium