在Go中嵌入而不是继承 [英] Embedding instead of inheritance in Go
问题描述
你对这个设计决定有何看法？它有什么优势和缺点？
链接：
在评论中，您想知道嵌入的想法是否足以完全替代继承。我会说这个问题的答案是是。几年前，我用一个名为 Snit ，它使用组合和委派来排除继承。 Snit仍然与Go的方法大不相同，但在这方面他们有一些共同的哲学基础。它是一种将功能和责任连接在一起的机制，而不是类的层次结构。
正如其他人所说的，它确实涉及语言设计者想要支持。所有这些选择都有自己的利弊。我不认为最佳实践是一个必然适用于此的短语。我们可能会看到有人为Go最终开发一个继承层。
（对于熟悉Tcl的读者，我觉得Snit比语言的感觉稍微接近匹配，而不是 [incr Tcl ] 是.Tcl完全是关于代表团的，至少在我看来是这样。）
What is your opinion of this design decision? What advantages does it have and what disadvantages?
Links:
In a comment, you wondered if the embedding idea was enough to "replace inheritance completely". I would say the answer to that question is "yes". A few years ago I played very briefly with a Tcl OO system called Snit, which used composition and delegation to the exclusion of inheritance. Snit is still vastly different from Go's approach, but in that one respect they have some common philosophical ground. It's a mechanism for joining together pieces of functionality and responsibility, not a hierarchy for the classes.
As others have stated, it's really about what kind of programming practices the language designers want to support. All such choices come with their own pros and cons; I don't think "best practices" is a phrase that necessarily applies here. We will probably see someone develop an inheritance layer for Go eventually.
(For any readers familiar with Tcl, I felt Snit to be a slightly closer match to the "feel" of the language than [incr Tcl] was. Tcl is all about the delegation, at least to my way of thinking.)
这篇关于在Go中嵌入而不是继承的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
