Golang Object Oriented Design

Golang Object Oriented Design
nathany.com

Yet Go keeps that old OO concept of method receivers. Why? I never found it very plausible to have one special case parameter with its very own syntax, but with type level encapsulation it did at least have some justification.

Without this kind of encapsulation, the only remaining purpose of the receiver is method dispatch. But why dispatch based on the type of one parameter and not the others? Multimethods would have been the logical conclusion of the OO cleanup that Go's designers apparently intended to achieve.

For example, say you're writing a CMS and want to make strings like the article title to be used in the URL (for readable URLs and SEO), displayed in HTML (eg inside heading tags) and also potentially used for string comparisons, you'd need to have a function to URL / HTML encode the string and you'd need to remember to do it each time you outputted the string. This can make it very easy to introduce vulnerabilities where you forget to HTML encode the string. With methods, you can force the developer to state which format to output the string as:

    type DisplayText struct {
        Value string
    }
    
    func (dt DisplayText) HTMLEscaped() string {
        return html.EscapeString(dt.Value)
    }
    
    func (dt DisplayText) URLEscaped() string {
        return url.QueryEscape(dt.Value)
    }
    
    var article_title DisplayText

    fmt.Println(article_title.HTMLEscaped)

    fmt.Println(html.EscapeString(article_title))