I'm new to Go, and one of the first things I want to do is to port my little marked-up-page-generation library to Go. The primary implementation is in Ruby, and it is very much "classical object orientation" in its design (at least as I understand OO from an amateur programmer's perspective). It models how I see the relationship between marked-up document types:
Page
/ \
HTML Page Wiki Page
/ \
HTML 5 Page XHTML Page
For a small project, I might do something like this (translated to the Go I now want):
p := dsts.NewHtml5Page()
p.Title = "A Great Title"
p.AddStyle("default.css")
p.AddScript("site_wide.js")
p.Add("<p>A paragraph</p>")
fmt.Println(p) // Output a valid HTML 5 page corresponding to the above
For larger projects, say for a website called "Egg Sample", I subclass one of the existing Page types, creating a deeper hierarchy:
HTML 5 Page
|
Egg Sample Page
/ | \
ES Store Page ES Blog Page ES Forum Page
This fits well into classical object-oriented design: subclasses get a lot for free, and they just focus on the few parts that are different from their parent class. EggSamplePage can add some menus and footers that are common across all Egg Sample pages, for example.
Go, however, does not have a concept of a hierarchy of types: there are no classes and there is no type inheritance. There's also no dynamic dispatch of methods (which seems to me to follow from the above; a Go type HtmlPage is not a "kind of" Go type Page).
Go does provide:
It seems those two tools should be enough to get what I want, but after several false starts, I'm feeling stumped and frustrated. My guess is that I'm thinking about it wrong, and I'm hoping someone can point me in the right direction for how to do this the "Go way".
This is a specific, real problem I'm having, and as such, any suggestions about solving my particular problem without addressing the broader question are welcome. But I'm hoping the answer will be in the form of "by combining structures, embedding, and interfaces in such-and-such a manner, you can easily have the behavior you want" rather than something that sidesteps that. I think many newcomers to Go transitioning from classical-OO languages likely go through a similar period of confusion.
Normally I would show my broken code here, but I've got several versions, each with their own problems, and I don't imagine including them will actually add any clarity to my question, which is already getting quite long. I will of course add code if it turns out to seem useful.
Things I've done:
To be a little more explicit about what I'm looking for:
I want to learn the idiomatic Go way of dealing with hierarchies like this. One of my more effective attempts seems the least Go-like:
type page struct {
Title string
content bytes.Buffer
openPage func() string
closePage func() string
openBody func() string
closeBody func() string
}
This got me close, but not all the way. My point right now is that it seems like a failed opportunity to learn the idioms Go programmers use in situations like this.
I want to be as DRY ("Don't Repeat Yourself") as is reasonable; I don't want a separate text/template for each type of page when so much of each template is identical to others. One of my discarded implementations works this way, but it seems it would become unmanageable once I get a more complex hierarchy of page types as outlined above.
I'd like to be able to have a core library package that is usable as-is for the types that it supports (e.g. html5Page and xhtmlPage), and is extensible as outlined above without resorting to copying and editing the library directly. (In classical OO, I extend/subclass Html5Page and make a few tweaks, for example.) My current attempts haven't seemed to lend themselves to this very well.
I expect the correct answer won't need much code to explain the Go way of thinking about this.
Update: Based on the comments and answers so far, it seems I wasn't so far off. My problems must be a little less generally design-oriented than I thought, and a little more about exactly how I'm doing things. So here's what I'm working with:
type page struct {
Title string
content bytes.Buffer
}
type HtmlPage struct {
page
Encoding string
HeaderMisc string
styles []string
scripts []string
}
type Html5Page struct {
HtmlPage
}
type XhtmlPage struct {
HtmlPage
Doctype string
}
type pageStringer interface {
openPage() string
openBody() string
contentStr() string
closeBody() string
closePage() string
}
type htmlStringer interface {
pageStringer
openHead() string
titleStr() string
stylesStr() string
scriptsStr() string
contentTypeStr() string
}
func PageString(p pageStringer) string {
return headerString(p) + p.contentStr() + footerString(p)
}
func headerString(p pageStringer) string {
return p.openPage() + p.openBody()
}
func HtmlPageString(p htmlStringer) string {
return htmlHeaderString(p) + p.contentStr() + footerString(p)
}
func htmlHeaderString(p htmlStringer) string {
return p.openPage() +
p.openHead() + p.titleStr() + p.stylesStr() + p.scriptsStr() + p.con tentTypeStr() +
p.openBody()
}
This works, but it has several problems:
String() method that does the right thing, rather than having to use a function.I strongly suspect that I'm doing something wrong and that there are Go idioms that could make this better.
I'd like to have a String() method that does the right thing, but
func (p *page) String( string {
return p.headerString() + p.contentStr() + p.footerString()
}
will always use the page methods even when used through an HtmlPage, due to lack of dynamic dispatch anywhere but with interfaces.
With my current interface-based page generation, not only do I not get to just do fmt.Println(p) (where p is some kind of Page), but I have to specifically choose between fmt.Println(dsts.PageString(p)) and fmt.Println(dsts.HtmlPageString(p)). That feels very wrong.
And I'm awkwardly duplicating code between PageString() / HtmlPageString() and between headerString() / htmlHeaderString().
So I feel like I'm still suffering design issues as a result of to some extent still thinking in Ruby or Java rather than in Go. I'm hoping there's a straightforward and idiomatic Go way to build a library that has something like the client interface I've described.
I seem to have come up with a workable solution, at least for my current task. After reading all of the advice here and talking to a friend (who doesn't know Go, but has other experience trying to model apparently hierarchical relationships without language support for type inheritance) who said "I ask myself 'What else is it? Yes, it's a hierarchy, but what else is it, and how can I model that?'", I sat down and rewrote my requirements:
I want a library with a client interface with a flow something like this:
Instantiate a page creation object, likely specifiying the format it will generate. E.g.:
p := NewHtml5Page()
Optionally set properties and add content. E.g.:
p.Title = "FAQ"
p.AddScript("default.css")
p.Add("<h1>FAQ</h1>
")
Generate the page. E.g.:
p.String()
And the tricky part: Make it extensible, such that a website named Egg Sample could easily leverage the library to make new formats based on existing ones, which themselves can form the basis of further sub-formats. E.g.:
p := NewEggSamplePage()
p2 := NewEggSampleForumPage()
Thinking about how to model that in Go, I decided that the clients really don't need a type hierarchy: they never need to treat an EggSampleForumPage as an EggSamplePage or an EggSamplePage as an Html5Page. Rather, it seemed to boil down to wanting my "subclasses" to each have certain points in the page where they add content or occasionally have different content from their "superclass". So it's not a question of behavior, but one of data.
That's when something clicked for me: Go doesn't have dynamic dispatch of methods, but if a "subtype" (a type that embeds a "supertype") changes a data field, methods on the "supertype" do see that change. (This is what I was working with in the very un-Go-like attempt shown in my question, using function pointers rather than methods.) Here's an excerpt of what I ended up with, demonstrating the new design:
type Page struct {
preContent string
content bytes.Buffer
postContent string
}
type HtmlPage struct {
Page
Title string
Encoding string
HeadExtras string
// Exported, but meant as "protected" fields, to be optionally modified by
// "subclasses" outside of this package
DocTop string
HeadTop string
HeadBottom string
BodyTop string
BodyAttrs string
BodyBottom string
DocBottom string
styles []string
scripts []string
}
type Html5Page struct {
*HtmlPage
}
type XhtmlPage struct {
*HtmlPage
Doctype string
}
func (p *Page) String() string {
return p.preContent + p.content.String() + p.postContent
}
func (p *HtmlPage) String() string {
p.preContent = p.DocTop + p.HeadTop +
p.titleStr() + p.stylesStr() + p.scriptsStr() + p.contentTypeStr() +
p.HeadExtras + p.HeadBottom + p.BodyTop
p.postContent = p.BodyBottom + p.DocBottom
return p.Page.String()
}
func NewHtmlPage() *HtmlPage {
p := new(HtmlPage)
p.DocTop = "<html>
"
p.HeadTop = " <head>
"
p.HeadBottom = " </head>
"
p.BodyTop = "<body>
"
p.BodyBottom = "</body>
"
p.DocBottom = "</html>
"
p.Encoding = "utf-8"
return p
}
func NewHtml5Page() *Html5Page {
p := new(Html5Page)
p.HtmlPage = NewHtmlPage()
p.DocTop = "<!DOCTYPE html>
<html>
"
return p
}
While it could perhaps use some cleaning up, it was extremely easy to write once I had the idea, it works perfectly (as far as I can tell), it doesn't make me cringe or feel like I'm fighting the language constructs, and I even get to implement fmt.Stringer like I wanted to. I've successfully generated both HTML5 and XHTML pages with my desired interface, as well as "subclassed" Html5Page from client code and used the new type.
I consider this a success, even if it doesn't provide a clear and universal answer to the question of modeling hierarchies in Go.
First, a warning : deep hierarchies are painful to adapt in all languages. Deep hierarchical structural modeling is often a trap : it's intellectually satisfying at first but ends as a nightmare.
Then, Go has embedding, which is really a composition but provides most of what is generally needed with (potentially multiple) inheritance.
For example, let's look at this :
type ConnexionMysql struct {
*sql.DB
}
type BaseMysql struct {
user string
password string
database string
}
func (store *BaseMysql) DB() (ConnexionMysql, error) {
db, err := sql.Open("mymysql", store.database+"/"+store.user+"/"+store.password)
return ConnexionMysql{db}, err
}
func (con ConnexionMysql) EtatBraldun(idBraldun uint) (*EtatBraldun, error) {
row := con.QueryRow("select pv, pvmax, pa, tour, dla, faim from compte where id=?", idBraldun)
// stuff
return nil, err
}
// somewhere else:
con, err := ms.bd.DB()
defer con.Close()
// ...
somethings, err = con.EtatBraldun(id)
As you can see, with just embedding I could :
ConnexionMysqlEtatBraldun*sql.DB, like Close of QueryRowAnd I could embedd more than one type. Or "subtype" my ConnexionMysql type.
In my opinion it's a good compromise and it helps avoiding the traps and rigidity of deep inheritance hierarchies.
I say it's a compromise, because it's clear Go isn't an OOP language. The lack of function overriding, as you saw, prevents the usual solution of having methods in a "superclass" composing the calls of "subclasses" methods.
I understand this may be disturbing, but I'm not sure I really miss the weight and verbosity of the usual hierarchy based solutions. As I said, there are fine at first but painful when it gets complex. That's why I suggest you try the Go way :
Go interfaces can be used to reduce the need for inheritance. In fact your page could be an interface (or more idiomatically a few interfaces) and a struct :
type pageOpenerCloser interface {
openPage func() string
closePage func() string
openPage func() string
closePage func() string
}
type page struct {
Title string
content bytes.Buffer
}
As you can't rely on a String() method defined on an implementation of pageOpenerCloser to simply call a closeBody method defined on the same implementation, you must use functions, not methods to do part of the work, what I see as composition : you must pass your instance of pageOpenerCloser to a Composing functions that will call the right implementations.
This means
I feel this reduces the clutter and helps make a Go program small and understandable.
I think it is not possible to answer your question satisfyingly. But let's start with a short analogy from a different context, to avoid any generally accepted ideas about programming (for example, many programmers believe that OOP is the "right way" to program, because that is what they have done for years now).
Let's suppose you are playing a classical game called Bridge Builder. The goal of this game is to build a bridge on top of pillars, so that a train can pass from one side to the other. One day, after mastering the game for years, you decide that you want to try something new. Let's say Portal 2 :)
You easily manage the first level, but you can't figure out how you can get to platform on the other side at the 2nd one. So you ask a friend: "Hey, how can I place pillars in Portal 2"? Your friend might look sightly confused, but he might tell you that you can pick up those boxes and place them on top of each other. So, you immediately start collecting all boxes you can find to build your bridge to your other side of the room. Well done!
Anyway, after a couple of hours, you find Portal 2 really frustrating (it takes ages to collect the blocks and the levels are really difficult). So you stop playing.
So, what went wrong here? First, you assumed that one technique from one game, might work well in another. Second, you haven't asked the right question. Instead of telling your friend about your problem ("how can I get to that platform over there?") you asked him how you can archive those things you are used to in other games. If you have asked the other question, your friend might have been able to tell you that you could use your portal gun to create a red and blue portal and walk through.
It is really frustrating to try to port a well-written Ruby / Java / etc. program to Go. One thing that works well in one language, might not work that well in another. You haven't even asked us, what problem you are trying to solve. You have just posted some useless boilerplate code that shows some class hierarchies. You won't need that in Go because Go's interfaces are more flexible. (A similar analogy could be drawn between Javascript's prototyping and people who try to program in a OOP-way in Javascript).
At the beginning, it's hard to came up with good designs in Go, especially if you are used to OOP. But the solutions in Go are usually smaller, more flexibly and much easier to understand. Take a close look at all those packages in the Go standard library and other external packages. For example, I think that leveldb-go is much easier and more straight-forward to understand than leveldb, even if you know both languages well.
Inheritance combines two concepts. Polymorphism and code sharing. Go separates these concepts.
A lot of people coming from OOP languages forget about functions and get lost using just methods.
Because Go separates these concepts you have to think about them individually. What is the relationship between 'Page' and 'Egg Sample Page'. It is an "is a" relationship or is it a code sharing relationship?
Maybe try to solve your problem like this:
One thing I usually find helpful is to think of interfaces as capturing functionality and structs as capturing data.