Sae*_*aew 76 java static playframework playframework-1.x
哇,玩!框架有很多静态方法.在我上学的地方,我们被告知永远不会使用任何静力学,但玩!使用它就像没有明天一样.那是不是很好？如果是这样,为什么？
我们(7个人和我)正计划使用Play!涉及Web应用程序的项目框架.我们决定玩Play!因为它看起来很有趣,我们所有人都已经知道Java并且任务很难,所以我们想要专注于实际的任务,而不是学习如何用不同的语言编程.
我们总是说,但是,永远不要用"静在我们开发的任何Java程序,但是当我看着玩!......好吧......大约一半的方法都是静态的.</夸张>
我想,至少,我们可以使用单例对象(通过使用Scala,例如^^)来编程我们的项目,但我非常担心框架本身实际上有多少静态.
那么,我应该关注这个吗？玩的方式!开发人员编程使它成为所有这些静态不会造成问题的？
(例如,这个主题有一个关于为什么要不惜一切代价避免静态成员的咆哮.)
小智 95
Play只有在有意义时才使用静态方法:
dde*_*any 34
Play框架不是一个很好的演示,当使用静态是合适的,也不能证明你的老师是错的.Play是一种作弊行为,解决了Java语言之外的静态问题.
关键问题是你必须并行处理多个HTTP请求,静态字段是"全局的".因此,对于某些事情,每个线程需要一个实例(甚至更好,每个HTTP请求一个实例),但其中一些实例是由Play中的静态方法返回的.这很有效,因为玩!使用ThreadLocal-s很重,因此它解决了Java语言之外的静态问题.但那不是一切.有人说控制器方法是正确的静态.当然,但是在普通的Java中它会很不方便,因为你不能在没有某种前缀的情况下访问特定于请求的数据,比如req.in req.session,然后你仍然必须req从某个地方获取,比如作为静态控制器方法的参数,这更麻烦.然而在Play中你可以直接写作session和喜欢,它们只是静态字段.那是因为Play使用字节码检测将所有静态字段引用更改为更智能的东西.同样,Java语言之外的解决方案.那些不是最后的静态字段.
所以,一般来说,避免非最终静态.Play虽然为你带来了魔力,所以在这种情况下不要害怕它们.
unw*_*ind 15
从一个非常简单的介绍一下,我会说这样的有道理:web请求是无状态的,所以是没有对象接收请求(=方法).因此,将诸如"/ articles/archive？date = 08/01/08&page = 2"之类的URI映射到一个名为archive()on 的静态方法,我想,你的应用程序类是有意义的.
编辑
现在在Play 2.4中,注射自动完成.所以只需在文件中的控制器路径的开头添加@ routes就可以了:
GET / @controllers.Application.index()
对于旧版本(2.1到2.3),您必须覆盖Global类中的getControllerInstance,如Documentantion中所述.
与编程中的任何内容一样,永远不会是正确的答案.就像往常一样.总有例外,正确的答案总是"它取决于".
确实,在纯粹的OO中(我都是这样),静力学的空间很小.但有时它们才有意义也是如此.
经典的例子是实用方法.当然,如果我们可以将我们的abs()方法附加到Integer 会更好.但我们不能; 所以我们坚持了下来Math.abs(int i).
我倾向于认为,当一个方法与实例本身无关时,将方法设置为静态是正确的.例如,在课堂上Person,您可以使用一个方法来获取人员列表,并返回今天有生日的人数.如果计算所需的数据是私有的(OO纯粹主义者会理解的东西;)),也许你只能在类本身中执行此操作,但该方法显然与单个Person实例无关.
另一件事是内部课程.如果不需要与包含类型的关系,通常希望将它们设置为静态.
我从未见过Play!但如果你说它超过50%是静态的,那么我猜它可能设计得很糟糕.那也不例外; 很多框架都是.不要让它让你失望.绝对不要向它学习!
但如果它有效,你仍然可以使用它.
| 归档时间： |
|
| 查看次数： |
14916 次 |
| 最近记录： |