了解围棋中的本地界面设计

2020-07-04 00:54:31

甚至不要看代码。先看看这个。你要按照非常具体的顺序来看代码,心里要有非常具体的东西,所以不要作弊!

人们对接口包或某种可共享接口的渴望并不少见。这通常是你在其他语言中处理界面的方式,这也是我开始做事情的方式,当我搬到Go的时候。

这在纸面上是有意义的。Dry(不要重复自己)指示您应该将公共代码移动到公共区域以供重用。如果你有很多东西需要使用这个界面,你为什么不用呢?

这个示例包含几个包含一些简单代码的超级基本软件包,重要的不是运行它们时它们实际做了什么,重要的是它们是如何构建的,以及您从高层次上阅读它们可以理解它们什么。

这些包包含一些处理用户的功能和一个计分器-用户,可用于某种排行榜。也许是游戏,也许是社交网络,也许是美宝莲。无关紧要。您可以从数据库中获取用户信息、奖励积分和顶级用户。此外,您还可以向用户发送通知,可能会为他们提供代码或促销/奖励等信息。

db包处理所有实际的数据库命令。它完全是模拟的,因为实现并不重要。您可以想象在这里编写一些实际的数据库访问代码。

通知包负责向用户发送通知。也许它是一个电子邮件,一个推送通知;再说一次,实现在这里并不重要。请注意,内部代码会做一些很酷的事情。

处理程序包包含一些构建HTTP处理程序的函数,然后可以在服务器中使用这些处理程序。我没有深入到真正实现服务器的程度,但这在这里应该不重要。在这种情况下,我们只需要db包。

排行榜软件包有一些功能,可以抓取顶级用户并向他们发送通知。这不是特别令人兴奋,但足以需要数据库和通知。

cmd中有一个基本的主干。请转到cmd来演示如何将数据库和通知实例传递给处理程序和排行板比特。

你还没看代码,对吧?太棒了。我就知道我可以信任你。

假设你刚刚被雇佣,一个叫埃弗特拉斯的混蛋留下了一些优雅的代码,你现在负责维护和添加功能。这就是你现在的生活。祝贺你。

所以你第一天坐在办公桌前,然后.。你从哪里开始呢?

我要问你的第一个问题是:你会先看哪一个套餐?

如果没有文档,检查main.go可能是个不错的选择。然后,您会看到正在使用的主要包,以及处理程序和排行榜似乎是如何使用数据库和传递给它们的通知来做一些高级工作的。

在这一点上,我强烈认为你应该进入操纵者或排行榜。直接进入数据库或通知不会告诉你系统做了什么,只会告诉你它是如何与一些较低级别的资源交互的。

我们选排行榜吧,因为我喜欢。好的,您现在可以查看代码了。到这儿来。

等等,什么?您看到传入了一个数据库和一个通知实例,这是什么?

乔伊,就是这样。因为这个函数准确地告诉您让排行榜正常工作需要哪些功能!

键入TopUserGetter interface{GetTopUsers(CTX上下文。context,count int)([]*db.。User,Error)}键入TopScoreNotifier接口{NotifyTopScore(CTX上下文。Context,id String,Score int)Error}Funcc New(topUserGetter TopUserGetter,topScoreNotifier TopScoreNotifier)*Leaderboard{//.}。

想象一下,如果一个叛逆的C#编码器提供了一些IDB接口,其中包含50个不同的函数签名,但所有需要的排行榜都是这个。你怎么知道的?你必须仔细检查所有的代码和跟踪使用了哪些调用。一点也不好玩。如果最初的目的是让LeaderBoard只用于建筑目的,但IDB上有这个简洁的AwardPoints功能,并且有使用它的诱惑力,由此产生的公关会让高级开发人员哭泣,因为他们根本就不是这个意思。现在谁才是那个混蛋呢?

关键是,这些界面本身就是文档。它们确切地告诉您排行榜需要对外部世界做什么,这对于保持代码的整洁和极大地减少维护项目所需的部落知识是非常棒的。

当您编写代码并积极维护它时,很容易将某些代码正在做的事情视为理所当然。但是,您应该经常后退一步,考虑一下对于以前从未接触过您的代码的人来说,您的代码是什么样子的。每当你手头上有工具可以减轻进来的人的精神负担时,使用它们可能是个好主意。

看到这个模拟有多简单了吗?当我们只需要模拟更大整体中的一小部分时,模拟本身是完全可管理的,并且使我们可以很容易地清晰地设置我们想要测试的任何场景。

等等,我听到你说。如果我们的接口包还包括用于测试目的的模拟实现,该怎么办?那样的话,我们就不需要重写任何嘲弄了!美洲开发银行万岁!

起初,这听起来完全合理,是的。问题是,嘲弄将很快开始增长,增长。因为不同的包需要设置特定的测试场景,所以您将开始添加奇怪的配置,以便在模拟中以某种方式进行设置。然后突然你意识到你的模拟已经变得足够复杂,需要它自己的测试,因为调整一些东西突然破坏了依赖于模拟的实际测试,而且.。嗯。我已经走上那条路了,从我的错误中吸取教训。

像这样的小的、瘦的、自给自足的嘲弄最终可能会在某种程度上被复制,而这并不总是像你所能做到的那样枯燥。但考虑一下权衡。

现在您已经重新考虑了自包含接口,现在来看一下代码的其余部分。我到处都加了评论,想对你说教,别担心。操控是很好的下一步。

当您开始查看数据库代码时,请注意其中有一些其他软件包尚未使用的Stuffin。你不需要知道数据库可以做所有这些事情。您只需担心这些包需要db来做什么。这种心态使您可以创建更独立、更易于理解的代码。

Go接口不像C#或Java接口那样工作。它们允许您非常清楚地声明所需的依赖关系,这带来了一些您可以从其他语言中轻松获得的巨大好处。不要做一个干巴巴的狂热者来对抗这件事。拥抱它吧!