FAQ
This may seem like a trivial question, but I'm curious how people choose
between writing a function as a standalone function in the classic
procedural sense and when they write it as a method attached to an object.
Go is neither a purely procedural or an object oriented language, and I'm
finding it a little hard to decide which style to use and when.

For example, are methods primarily about satisfying interfaces and
everything else should be a function? Do we choose between methods and
functions merely pragmatically, for example, using methods if we want to
get some method chaining magic happening? Or can/should methods be used
just as in OO languages to describe how a data object can behave? If so,
then when is it best to write functions?

Cheers,
Torrance

--

Search Discussions

  • Kevin Gillette at Oct 15, 2012 at 11:37 pm
    Methods (are the only way to) satisfy interfaces in Go, yes, so sometimes
    you'll even write interfaces on an empty struct type (which by definition,
    can have no data/state of its own) just to satisfy an interface with static
    behavior -- this is sometimes done for net/http handlers. However, if it
    seems suitable for a type to modify itself, use methods.

    For example, if you were going to provide a single alternative hashtable
    implementation, you'd just put methods on the type, as opposed to
    package-level functions.

    If you want to provide common 'base' implementations for interfaces, as
    you'd do in OOP languages with overridable base class methods, functions
    are used for that.

    For example, if you provided a number of different hashtable
    implementations with different performance/storage characteristics, but
    with semantically identical operations, you'd make them each implement a
    common, minimal 'Map' interface, and then for any tedious,
    difficult-to-implement, but common (and non-performance critical) behaviors
    that can be based on those minimal interface methods, you provide a
    package-level function that implements that behavior once (an example of
    this is the sort package), and you can also provide something like:

    type MapType int
    const (
    TreeMap MapType = iota
    HashMap
    // etc
    )
    func MakeMap(backend MapType) Map { ... }

    The above MapMap func would take a value which indicates the underlying
    implementation to use, and would return one of the implementations that had
    been registered or hardcoded into the package. An example of this is the
    crypto package.
    On Monday, October 15, 2012 3:57:27 PM UTC-6, Torrance Hodgson wrote:

    This may seem like a trivial question, but I'm curious how people choose
    between writing a function as a standalone function in the classic
    procedural sense and when they write it as a method attached to an object.
    Go is neither a purely procedural or an object oriented language, and I'm
    finding it a little hard to decide which style to use and when.

    For example, are methods primarily about satisfying interfaces and
    everything else should be a function? Do we choose between methods and
    functions merely pragmatically, for example, using methods if we want to
    get some method chaining magic happening? Or can/should methods be used
    just as in OO languages to describe how a data object can behave? If so,
    then when is it best to write functions?

    Cheers,
    Torrance
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 15, '12 at 10:28p
activeOct 15, '12 at 11:37p
posts2
users2
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase