README
¶
Interface and Composition Design
Composition goes beyond the mechanics of type embedding and is more than just a paradigm. It is the key for maintaining stability in your software by having the ability to adapt to the data and transformation changes that are coming.
Notes
- This is much more than the mechanics of type embedding.
- Declare types and implement workflows with composition in mind.
- Understand the problem you are trying to solve first. This means understanding the data.
- The goal is to reduce and minimize cascading changes across your software.
- Interfaces provide the highest form of composition.
- Don't group types by a common DNA but by a common behavior.
- Everyone can work together when we focus when we do and not what we are.
Links
http://golang.org/doc/effective_go.html#embedding
https://www.goinggo.net/2016/10/reducing-type-hierarchies.html
http://www.goinggo.net/2015/09/composition-with-go.html
Design Guidelines
- Learn about the design guidelines for composition.
Code Review
Grouping Types
Grouping By State (Go Playground)
Grouping By Behavior (Go Playground)
Decoupling
Struct Composition (Go Playground)
Decoupling With Interface (Go Playground)
Interface Composition (Go Playground)
Decoupling With Interface Composition (Go Playground)
Conversion and Assertions
Interface Conversions (Go Playground)
Runtime Type Assertions (Go Playground)
Mocking
Package To Mock (Go Playground)
Client (Go Playground)
Exercises
Exercise 1
Using the template, declare a set of concrete types that implement the set of predefined interface types. Then create values of these types and use them to complete a set of predefined tasks.
Template (Go Playground) | Answer (Go Playground)
All material is licensed under the Apache License Version 2.0, January 2004.
Directories
¶
| Path | Synopsis |
|---|---|
|
assertions
|
|
|
example1
command
Sample program demonstrating when implicit interface conversions are provided by the compiler.
|
Sample program demonstrating when implicit interface conversions are provided by the compiler. |
|
example2
command
Sample program demonstrating that type assertions are a runtime and not compile time construct.
|
Sample program demonstrating that type assertions are a runtime and not compile time construct. |
|
decoupling
|
|
|
example1
command
Sample program demonstrating struct composition.
|
Sample program demonstrating struct composition. |
|
example2
command
Sample program demonstrating decoupling with interfaces.
|
Sample program demonstrating decoupling with interfaces. |
|
example3
command
Sample program demonstrating interface composition.
|
Sample program demonstrating interface composition. |
|
example4
command
Sample program demonstrating decoupling with interface composition.
|
Sample program demonstrating decoupling with interface composition. |
|
exercises
|
|
|
exercise1
command
Using the template, declare a set of concrete types that implement the set of predefined interface types.
|
Using the template, declare a set of concrete types that implement the set of predefined interface types. |
|
grouping
|
|
|
example1
command
This is an example of using type hierarchies with a OOP pattern.
|
This is an example of using type hierarchies with a OOP pattern. |
|
example2
command
This is an example of using composition and interfaces.
|
This is an example of using composition and interfaces. |
|
mocking
|
|
|
example1
command
Sample program to show how you can personally mock concrete types when you need to for your own packages or tests.
|
Sample program to show how you can personally mock concrete types when you need to for your own packages or tests. |
|
example1/pubsub
Package pubsub simulates a package that provides publication/subscription type services.
|
Package pubsub simulates a package that provides publication/subscription type services. |