diff options
author | Andrew Gerrand <adg@golang.org> | 2011-03-04 13:11:07 +1100 |
---|---|---|
committer | Andrew Gerrand <adg@golang.org> | 2011-03-04 13:11:07 +1100 |
commit | aef4e1c3492908425d4cefd78ae8dd8a765988b9 (patch) | |
tree | 383fd692af3fca11fa12e86c2b9f3234f3f066b3 | |
parent | ee1cb829ac6d3b3a79b4fe92d9cea1d19baf15bf (diff) | |
download | go-aef4e1c3492908425d4cefd78ae8dd8a765988b9.tar.gz go-aef4e1c3492908425d4cefd78ae8dd8a765988b9.zip |
doc: add "implements" question to FAQ
R=r, fw, gri, r2, yiyus
CC=golang-dev
https://golang.org/cl/4248051
-rw-r--r-- | doc/go_faq.html | 65 |
1 files changed, 65 insertions, 0 deletions
diff --git a/doc/go_faq.html b/doc/go_faq.html index 0d5a6000ca..4be8110682 100644 --- a/doc/go_faq.html +++ b/doc/go_faq.html @@ -508,6 +508,71 @@ Regarding operator overloading, it seems more a convenience than an absolute requirement. Again, things are simpler without it. </p> +<h3 id="implements_interface"> +Why doesn't Go have "implements" declarations?</h3> + +<p> +A Go type satisfies an interface by implementing the methods of that interface, +nothing more. This property allows interfaces to be defined and used without +having to modify existing code. It enables a kind of "duck typing" that +promotes separation of concerns and improves code re-use, and makes it easier +to build on patterns that emerge as the code develops. +The semantics of interfaces is one of the main reasons for Go's nimble, +lightweight feel. +</p> + +<p> +See the <a href="#inheritance">question on type inheritance</a> for more detail. +</p> + +<h3 id="guarantee_satisfies_interface"> +How can I guarantee my type satisfies an interface?</h3> + +<p> +You can ask the compiler to check that the type <code>T</code> implements the +interface <code>I</code> by attempting an assignment: +</p> + +<pre> +type T struct{} +var _ I = T{} +</pre> + +<p> +If <code>T</code> doesn't implement <code>I</code>, the mistake will be caught +at compile time. +</p> + +<p> +If you wish the users of an interface to explicitly declare that they implement +it, you can add a method with a descriptive name to the interface's method set. +For example: +</p> + +<pre> +type Fooer interface { + Foo() + ImplementsFooer() +} +</pre> + +<p> +A type must then implement the <code>ImplementsFooer</code> method to be a +<code>Fooer</code>, clearly documenting the fact. +</p> + +<pre> +type Bar struct{} +func (b Bar) ImplementsFooer() {} +func (b Bar) Foo() {} +</pre> + +<p> +Most code doesn't make use of such constraints, since they limit the utility of +the interface idea. Sometimes, though, they're necessary to resolve ambiguities +among similar interfaces. +</p> + <h2 id="values">Values</h2> |