设置命令监听器风格偏好疑问
为什么有些人喜欢
.setCommandListener(this)
更频繁地
.setCommandListener(new CommandListener(){})
使用?在什么情况下我应该使用第二个,为什么? 我认为这只是风格问题还是有特殊问题?
Why do some people prefer to use
.setCommandListener(this)
over
.setCommandListener(new CommandListener(){})
more often? In what case should I use the second one and why?
I am assuming it's just a matter of style or is there a particular issue?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
如果使用“this”,则必须在类中实现监听器,然后可以在监听器的实现方法中访问类的字段。
如果您使用第二个(新侦听器...),那么如果您不需要访问类中的许多其他内容,那么它可能是更具可读性的代码。
If you use "this", you must implement the listener to the class, and then you can access fields of class in the implemented methods of listener.
If you use the second one(new Listener...) then it might be more readable code if you don't need to access many other stuff in your class.
setCommandListener(this)
在“玩具代码”中明显更容易阅读。我认为这就是为什么我看到它在许多入门级教程中使用,而作者只是不想太深入。看起来初学者程序员只是盲目地从教程中复制这个反模式,而没有给予额外的思考。
根据我的经验,对于更复杂的代码,
setCommandListener(new CommandListener(){/*..*/})
更容易维护和阅读。另请注意,在两种情况下您都可以访问类的字段 ,后者需要使用 限定这一点:
顺便说一句,我是否提到过以上方法还安全吗?它保证您期望的特定屏幕的侦听器正是您设置的侦听器。
比如说,如果您直接重写 setCommandListener(this) 并运行它,您会注意到奇怪的行为 - 命令“go”现在将退出 midlet,而不是显示下一个屏幕:
setCommandListener(this)
is noticeably easier to read in "toy code". I think that's why I've seen it used in many entry level tutorials, where authors just don't want to get too deep.It also looks like beginner programmers just blindly copy this anti-pattern from tutorials, without giving it additional thought.
For more complicated code though
setCommandListener(new CommandListener(){/*..*/})
was in my experience much easier to maintain and read.Note also that you can access fields of class in both cases, just latter requires use of Qualified this:
BTW did I mention that above approach is also safer? It guarantees that the listener you expect for particular screen is exactly the one that you set.
Say, if you do a straightforward rewrite to setCommandListener(this) and run it, you'll notice weird behavior - command "go" will now quit the midlet instead of showing next screen: