Golang meetup about interfaces implementation and specificities.

1. WORKING WITH INTERFACES
GOLANG

2. DEVOPS @ OVH
WORKING IN CONTAINERS TEAM
@DEVATORIA

3. GO AND OBJECT ORIENTED
PROGRAMMING APPROACH

4. NO INHERITANCE,
NO SUBCLASSING,
NO TYPE HIERARCHY.

5. USER-DEFINED TYPES,
WITH BOUND FUNCTIONS

6. COMPOSITION

7. “POLYMORPHISM”
WITH INTERFACES

8. GO INTERFACES
FUNDAMENTALS

9. INTERFACES ARE
TYPES

10. INTERFACES ARE
BRINGING A KIND OF
POLYMORPHISM

11. INTERFACES ARE
SATISFIED IMPLICITLY

12. INTERFACES ARE CHECKED
AT COMPILE TIME

13. IT EXISTS AN EMPTY
INTERFACE,
AND EVERYTHING SATISFIES IT

14. YOU CAN CHECK IF A STRUCT
SATISFIES OR NOT AN INTERFACE,
EVEN IF YOU DO NOT KNOW ITS
TYPE

15. THERE IS A LOT OF BUILTIN
INTERFACES,
LIKE THE STRINGER INTERFACE

16. GO INTERFACES AND
MEMORY MANAGEMENT

17. THANK YOU
RUSS COX

18. COMPUTE TABLES CONTAINING ALL THE
METHOD CALLS
OR
DO A METHOD LOOKUP WITH CACHING

19. LET'S DECLARE A NEW
STRINGER INTERFACE

20. THE COMPILER IS COMPUTING A TABLE
FOR BINARY AND A TABLE FOR STRINGER
BINARY
[Type metadata]
Get() uint64
String() string
STRINGER
String() string

21. AT RUN TIME, THE
VARIABLE IS ALLOCATED
b := Binary(200)
200
Binary

22. NEXT, THE INTERFACE RUN TIME
COMPUTES AN INTERFACE TABLE (ITABLE)
b := Binary(200)
200
Binary
s := fmt.Stringer(b)
fmt.Stringer itable(Stringer, Binary)
...
itable
type(Binary)
(*Binary).String
type
fun[0]
tab
data

23. THE INTERFACE TYPE IS ALWAYS STRINGER
INTERFACES ARE NOT DYNAMICALLY TYPED

24. WITH THE EMPTY INTERFACE, WE CAN
OPTIMIZE THE MEMORY BY DO NOT CREATE A
NEW ITABLE
b := Binary(200)
200
Binary
any := (interface{})(b)
interface{}
type(Binary)type
data

25. THANK YOU!
@DEVATORIA