3 回答
TA贡献1853条经验 获得超6个赞
您正在尝试使用具有继承的面向对象设计模式。这不是在 Go 中如何做到这一点。此外,接口名称在 Java 或等效的面向对象语言中以“able”结尾。在 Go 中,约定是以 'er' 结束接口名称。
为了回答你关于岩石的问题,我建议所有可以碰撞到另一个物体的东西都实现 CollisonShape() 方法,返回一个 collison.Shaper(例如 Circle),你将用它来测试碰撞。这里collison是你的包的名称。
// This interface is defined in the collison package.
// Any object that may collide must implement that method.
type Collider interface {
CollisonShape() Shaper
}
// This function defined in the collison package
// test if two Collider collide into each other.
func Collide(c1, c2 Collider) bool {
shape1, shape2 := c1.CollisonShape(), c2.CollisonShape()
...
}
// This is how you would define an object that can collide.
type Rock struct {
shape *collison.Circle
...
}
// Implements the Collider interface.
// The return type must be the same as in the interface.
func (r *Rock) CollisonShape() collison.Shaper {
return r.shape
}
如您所见,我们使用一种方法来访问岩石的碰撞形状。这允许我们写
if collison.Collide(rock, spaceCraft) {...}
这回答了您关于如何获得 collison Shape of Rock 的问题。
如果要避免在 Collide() 函数中调用 CollisonShape() 方法,则必须直接传递 collison.Shaper。
Collide 方法将在 collison 包中定义为
func Collide(shape1, shape2 Shaper) bool {...}
然后你必须写
if collison.Collide(rock.shape, spacecraft.shape) {...}
这种设计会稍微高效一些,但要付出的代价是代码可读性较差,这是有经验的 Go 程序员所不喜欢的。
如果您希望 Circle 成为岩石中的嵌入式结构,则必须按以下方式定义它。嵌入形状可以节省 Circle 的分配时间和 GC 的一些工作。
type Rock struct {
shape collison.Circle
....
}
if collison.Collide(&rock.shape, &spacecraft.shape) {...}
如果要使用匿名嵌入式结构,则必须编写
type Rock struct {
Circle
....
}
if collison.Collide(&rock.Circle, &spacecraft.Rectangle) {...}
如您所见,代码的可读性越来越低,使用起来也越来越不方便。形状不再抽象。使用匿名嵌入式结构应该仅限于真正有意义的极少数情况。
通过使用最初建议的 CollisonShape() 方法,您可以轻松地将 Rock 结构更改为这种结构,而不会破坏任何代码。
type Rock struct {
shape collison.Circle
...
}
func (r *Rock) CollisonShape() collison.Shaper {
return &r.shape
}
现在制作形状和嵌入式结构。使用获取形状的方法将 Rock 的内部实现与对形状的访问分离。您可以更改 Rock 的内部实现,而无需更改其他地方的代码。
这是 Go 不支持继承的原因之一。它在基类和派生类之间创建了非常强的依赖和耦合。经验表明,随着代码的发展,人们常常会后悔这种耦合。对象组合是首选和推荐的,并且 Go 很好地支持。
如果效率是你的目标,那么每个碰撞器都应该有一个改变的位置和一个宽度和高度不变的边界框。您可以使用这些值为边界框重叠测试保存一些操作。但这是另一个故事。
- 3 回答
- 0 关注
- 192 浏览
添加回答
举报