Go Language Object Oriented Programming: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(65 intermediate revisions by the same user not shown)
Line 5: Line 5:
* [[Go_Language#Object_Oriented_Programming|Go Language]]
* [[Go_Language#Object_Oriented_Programming|Go Language]]
* [[Go Functions]]
* [[Go Functions]]
* [[Go_Interfaces#Overview|Go Interfaces]]
* [[Object-Oriented_Programming#Overview|Object-Oriented Programming]]
* [[Object-Oriented_Programming#Overview|Object-Oriented Programming]]


Line 12: Line 13:
Go provides syntax to associate an arbitrary [[Go_Language#Local_Type|local type]] with arbitrary functions, turning them into [[#Method|methods]] of that type. The local type can be a [[Go_Language#Type_Alias|type alias]], a <code>[[Go_Structs#Overview|struct]]</code> or a [[#Functions_as_Receiver_Types|function]]. In this context, "local" means a type that is defined in the same package as the function. That is why a programmer cannot add new methods to built-in types.
Go provides syntax to associate an arbitrary [[Go_Language#Local_Type|local type]] with arbitrary functions, turning them into [[#Method|methods]] of that type. The local type can be a [[Go_Language#Type_Alias|type alias]], a <code>[[Go_Structs#Overview|struct]]</code> or a [[#Functions_as_Receiver_Types|function]]. In this context, "local" means a type that is defined in the same package as the function. That is why a programmer cannot add new methods to built-in types.


<span id='Structs_as_Receiver_Types'></span><span id='Structs_as_Receiver_Type'></span>The most common pattern for implementing object-orientation is to use a <code>struct</code> as data encapsulation mechanism, optionally declaring fields as [[Go_Packages#Unexported_Members|unexported]], thus preventing direct access to them from outside the package, and then associating the struct with functions, by declaring the struct type as the [[#Receiver_Type|receiver type]] for the function and the functions into [[#Method|methods]] of the type. This construct is the closest equivalent to a class in other programming languages. The standard dot notation is then used to call a method on the instance of the receiver type.
<span id='Structs_as_Receiver_Types'></span><span id='Structs_as_Receiver_Type'></span>The most common pattern for implementing object-orientation is to use a <code>struct</code> as data encapsulation mechanism, optionally declaring fields as [[Go_Packages#Unexported_Members|unexported]], thus preventing direct access to them from outside the package, and then associating the struct with functions, by declaring the struct type as the [[#Receiver_Type|receiver type]] for those functions. The functions become [[#Method|methods]] of the type. This construct is the closest equivalent to a class in other programming languages. The standard dot notation is then used to call a method on the instance of the receiver type.


Go does not have formal [[Object-Oriented_Programming#Inheritance|inheritance]] and constructors. Inheritance can be replaced to a certain extent by composition, [[Go_Structs#Embedded_Fields|struct field embedding]] and [[Go_Interfaces#Overview|interfaces]], which support code reuse and [[#Polymorphism|polymorphism]].
Go does offer inheritance, overriding and polymorphism in the language syntax the same way other OOP languages do, but these features are available and can be implemented with a combination of [[Go_Structs#Embedded_Fields|struct field embedding]] and [[Go_Interfaces#Overview|interfaces]]. See: {{Internal|Go_Inheritance_and_Polymorphism#Overview|Go Inheritance and Polymorphism}}


=<span id='Method'></span>Methods=
=<span id='Method'></span>Methods=
 
{{Internal|Go_Methods#Overview|Go Methods}}
A '''method''' of a type is a function that was associated with the type, by declaring the type to be a [[#Receiver_Type|receiver type]] for that function, with the special syntax described below. If a method name starts with an uppercase character it is automatically [[Go_Language#Exported_Identifiers|exported]].
 
=Receiver Type=
 
A '''receiver type''' for a function is a type that is associated with the function with dedicated syntax:
 
<syntaxhighlight lang='go'>
func (<receiver_parameter_name> <receiver_type|receiver_type_pointer>) function_name(...) ... {
  ...
}
</syntaxhighlight>
 
Declaring a receiver type turns the function into a [[#Method|method]] of the type. Depending on whether we want to be able to modify the receiver instance in the method or not, the receiver type can be declared as a [[#Pointer_Receiver_Type|pointer receiver type]] or a [[#Value_Receiver_Type|value receiver type]].
 
<span id='Implicit_Parameter'></span>Regardless of whether we use a pointer or a value receiver type, the function gets an '''implicit parameter''', which is a pointer to the instance in case of a pointer receiver type, and a value of the type in case of a value recover type:
 
<syntaxhighlight lang='go'>
func function_name(<implicit_receiver_parameter> <receiver_type|receiver_type_pointer>, ...) ... {
  ...
}
</syntaxhighlight>
 
We call that '''receiver parameter'''. It is, loosely, the logical equivalent of the <code>[[Python_Language_OOP#The_self_Parameter|self]]</code> function parameter in Python and the implicit method parameter <code>this</code> in Java. The receiver parameter can be simply thought of as the first parameter of the function. In the underlying implementation, it is indeed not much else indeed.
 
As we write idiomatic Go code, it is common to use the first letter or a short abbreviation of the type as the name of the receiver. In our case, if the name of the type is <code>Color</code>, the name of the parameter is <code>c</code> or even <code>color</code>. We might even consider naming the receiver parameters with abbreviations of the interfaces they represent. See  [https://blog.heroku.com/neither-self-nor-this-receivers-in-go#naming-the-receiver this article] for arguments against naming that parameter "this" or "self".
 
==Value Receiver Type==
The syntax to declare a value receiver type for a function is:
<syntaxhighlight lang='go'>
func (<receiver_parameter_name> <receiver_type>) <function_name>(...) ... {
  ...
}
</syntaxhighlight>
Example:
<syntaxhighlight lang='go'>
type Color struct {
  color string
}
 
func (c Color) SomeMethod() string {
  return "dark " + c.color
}
</syntaxhighlight>
 
In the example above, <code>Color</code> is the receiver type, and <code>c</code> is the variable that refers to the particular receiver type value the method was invoked on. The invocation target is passed as '''value''' inside the function.
 
The method is invoked on the receiver type instances with the usual dot notation syntax:
<syntaxhighlight lang='go'>
color := Color{"blue"}
result := color.SomeMethod() // the method will return "dark blue"
</syntaxhighlight>
 
The invocation copies the <code>color</code> value into in the <code>c</code> variable inside the function, making <code>c</code> an [[#Implicit_Parameter|implicit parameter]] of the method. There is no formal <code>c</code> function parameter in the signature, yet the method body has access to <code>c</code>, which behaves similarly to any other function parameter. That is why the following syntax makes sense, and it also works. The syntax confirms that <code>SomeMethod()</code> is a method associated with the type <code>Color</code>, and when invoked with the instance of the type as its first (implicit) parameter, it behaves exactly as expected:
<syntaxhighlight lang='go'>
color := Color{"blue"}
Color.SomeMethod(color)
</syntaxhighlight>
 
Because the receiver instance is passed by value, hence a copy of that value is passed inside the function, the method cannot modify the invocation target instance. A [[#Pointer_Receiver_Type|pointer receiver type]] must be used if instead to modify the target.
 
==Pointer Receiver Type==
The syntax to declare a pointer receiver type for a function is:
 
<syntaxhighlight lang='go'>
func (<receiver_parameter_name> *<receiver_type>) <function_name>(...) ... {
  ...
}
</syntaxhighlight>
 
Example:
<syntaxhighlight lang='go'>
func (c *Color) SomeOtherMethod() {
  c.color = "dark " + c.color
  // (*c).color = "dark" + (*c).color is an equivalent, longer syntax. The compiler can handle the simpler syntax
}
 
...
 
color := Color{"blue"}
color.SomeOtherMethod() // equivalent with (&color).SomeOtherMethod()
fmt.Println(color) // will print "{dark blue}"
</syntaxhighlight>
 
In the example above, a pointer to a <code>Color</code> instance is passed inside the method, so the method can mutate the target instance it was invoked on. The invocation copies the pointer to the <code>Color{"blue"}</code> value into in the <code>c</code> variable inside the function, making <code>c</code> an [[#Implicit_Parameter|implicit parameter]] of the method. Similarly to the value receiver type syntax, there is no formal <code>c</code> function parameter in the signature, yet the method body has access to <code>c</code>, which behaves similarly to any other function parameter. That is why the following syntax makes sense, and it also works. The syntax confirms that <code>SomeMethod()</code> is a method associated with the type <code>*Color</code> (note that it is a pointer type), and when invoked with the pointer to a type instance as its first (implicit) parameter, it behaves exactly as expected:
<syntaxhighlight lang='go'>
color := Color{"blue"}
(*Color).SomeOtherMethod(&color)
</syntaxhighlight>
 
===Invoking on <tt>nil</tt> Pointers===
Since pointers are involved, methods declared with pointer receiver types may be invoked on a <code>nil</code> pointers, which will lead to a "invalid memory address or nil pointer dereference" panic:
<font size=-2>
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xbe79030]
goroutine 1 [running]:
main.(*Color).SomeOtherMethod(...)
        .../cmd/gotest/main.go:8
main.main()
        .../cmd/gotest/main.go:14 +0x10
Process finished with the exit code 2
</font>
 
If the implementation semantics allows it, the method may guard against <code>nil</code> pointers:
<syntaxhighlight lang='go'>
func (c *Color) SomeOtherMethod() {
  if c == nil {
    return
  }
  c.color = "dark " + c.color
}
</syntaxhighlight>
==Receiver Naming==
By convention, receivers are named using one or two characters that reflect the receiver type, because they typically appear on almost every line. Receiver names should be consistent cross a type's methods, do not use one name in one and other name in another.
<syntaxhighlight lang='go'>
func (b *Buffer) Read(p []byte) (n int, err error)
</syntaxhighlight>
<syntaxhighlight lang='go'>
func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request)
</syntaxhighlight>
Alos see: {{Internal|Go_Style#Receivers|Go Style}}
 
==Dot Notation works with Both Values and Pointers==
The Go compiler knows how to use the dot notation with both values and pointers.
 
There is no need to invoke a method defined with a pointer receiver type with:
<syntaxhighlight lang='go'>
(&variable).SomeMethod()
</syntaxhighlight>
This will work:
<syntaxhighlight lang='go'>
variable.SomeMethod()
</syntaxhighlight>
Similarly, inside the method, there is no need to dereference the pointer receiver type parameter:
<syntaxhighlight lang='go'>
func (v *SomeType) SomeMethod(...) {
  (*v).someField // not necessary
}
</syntaxhighlight>
This will work:
<syntaxhighlight lang='go'>
func (v *SomeType) SomeMethod(...) {
  v.someField
}
</syntaxhighlight>
 
==Mixing Value and Pointer Receiver Types==
When using pointer receivers, it is good programming practice to have all method use pointer receivers, or none of them use pointer receivers. If we mix value and pointer receivers, the IDE would detect that as static check warning:
 
<font size=-2>
  Struct Color has methods on both value and pointer receivers. Such usage is not recommended by the Go Documentation.
</font>
 
==Functions as Receiver Types==
 
<font color=darkkhaki>TODO: https://go.dev/blog/error-handling-and-go#simplifying-repetitive-error-handling</font>


=Encapsulation=
=Encapsulation=


Encapsulation in this context is giving access to data, but intermediated by the public methods that are defined with the data. This way, access to data is controlled.
Encapsulation in this context is giving access to private data, such as package-internal data or private struct fields, via public methods. This way, access to data is controlled.


Encapsulation can be implemented with [[Go_Language_Modularization#Encapsulation|package]] data.
Encapsulation can be implemented with [[Go_Language_Modularization#Encapsulation|package]] data and with structs, where the [[Go_Structs#Encapsulation_and_Private_Fields|"private" fields]] are declared using identifiers that start with lower cap letters, so they are not visible outside the package. Controlled access to them is given via accessor and mutator methods, or [[Go_Style#Getters_and_Setters|getters and setters]], which are functions that have been declared to use the struct as a receiver type:
 
Encapsulation can also be implemented with structs, where the [[Go_Structs#Encapsulation_and_Private_Fields|"private" fields]] are declared using identifiers that start with lower cap letters, so they are not visible outside the package. Controlled access to them is given via accessor and mutator methods, which are functions that have been declared to use the struct as a receiver type:


<syntaxhighlight lang='go'>
<syntaxhighlight lang='go'>
Line 193: Line 35:
}
}


func (c *Color) GetColor() string {
func (c *Color) Color() string {
return (*c).color
return (*c).color
}
}
Line 205: Line 47:
var c Color
var c Color
c.Init("blue")
c.Init("blue")
fmt.Println(c.GetColor()) // prints blue
fmt.Println(c.Color()) // prints blue
c.SetColor("red")
c.SetColor("red")
fmt.Println(c.GetColor()) // prints red
fmt.Println(c.Color()) // prints red
</syntaxhighlight>
</syntaxhighlight>
=Polymorphism=
Polymorphism is available in Go, but it is implemented a bit differently than in other object-oriented languages, in that it does not imply formal [[Go_Language_Object_Oriented_Programming#Inheritance|inheritance]] at language level, which is not available in Go. Polymorphism in Go is implemented using [[Go_Interfaces#Overview|interfaces]].
For a generic discussion on polymorphism, see: {{Internal|Object-Oriented_Programming#Polymorphism|Object-Oriented Programming &#124; Polymorphism}}
=<span id='Interface'></span>Interfaces=
=<span id='Interface'></span>Interfaces=
{{Internal|Go_Interfaces#Internal|Go Interfaces}}
{{Internal|Go_Interfaces#Internal|Go Interfaces}}
 
=<span id='Inheritance'></span><span id='Polymorphism'></span><span id='Overriding'></span>Inheritance and Polymorphism=
=Overriding=
{{Internal|Go_Inheritance_and_Polymorphism#Overview|Go Inheritance and Polymorphism}}
=Inheritance=
=TO DEPLETE=
 
<font color=darkkhaki>
 
Read and merge into document:
 
* https://go.dev/doc/faq#Is_Go_an_object-oriented_language
 
</font>

Latest revision as of 00:08, 2 September 2024

External

Internal

Overview

Go is an object-oriented language, but the object orientation programming model is relatively simple, compared with other object-oriented languages. It has been said about Go that is "weakly" object-oriented. Go does not use the term "class", there is no class keyword in the language. However, Go allows associating data with methods, which what a class in other programming languages really is.

Go provides syntax to associate an arbitrary local type with arbitrary functions, turning them into methods of that type. The local type can be a type alias, a struct or a function. In this context, "local" means a type that is defined in the same package as the function. That is why a programmer cannot add new methods to built-in types.

The most common pattern for implementing object-orientation is to use a struct as data encapsulation mechanism, optionally declaring fields as unexported, thus preventing direct access to them from outside the package, and then associating the struct with functions, by declaring the struct type as the receiver type for those functions. The functions become methods of the type. This construct is the closest equivalent to a class in other programming languages. The standard dot notation is then used to call a method on the instance of the receiver type.

Go does offer inheritance, overriding and polymorphism in the language syntax the same way other OOP languages do, but these features are available and can be implemented with a combination of struct field embedding and interfaces. See:

Go Inheritance and Polymorphism

Methods

Go Methods

Encapsulation

Encapsulation in this context is giving access to private data, such as package-internal data or private struct fields, via public methods. This way, access to data is controlled.

Encapsulation can be implemented with package data and with structs, where the "private" fields are declared using identifiers that start with lower cap letters, so they are not visible outside the package. Controlled access to them is given via accessor and mutator methods, or getters and setters, which are functions that have been declared to use the struct as a receiver type: 

type Color struct {
	color string
}

func (c *Color) Init(color string) {
	c.SetColor(color)
}

func (c *Color) Color() string {
	return (*c).color
}

func (c *Color) SetColor(color string) {
	(*c).color = color
}

...

var c Color
c.Init("blue")
fmt.Println(c.Color()) // prints blue
c.SetColor("red")
fmt.Println(c.Color()) // prints red

Interfaces

Go Interfaces

Inheritance and Polymorphism

Go Inheritance and Polymorphism
Retrieved from "https://kb.novaordis.com/index.php?title=Go_Language_Object_Oriented_Programming&oldid=112732"