玩！框架使用＆lt; lot＆gt;静力学

哇，玩！框架有很多静态方法。在我上学的地方，我们被告知永远不会使用任何静力学，但玩！使用它就像没有明天一样。那是不是很好？如果是这样，为什么？我们（7个人和我）正计划使用Play！涉及Web应用程序的项目框架。我们决定玩Play！因为它看起来很有趣，我们所有人都已经知道Java并且任务很难，所以我们想要专注于实际的任务，而不是学习如何用不同的语言编程。然而，我们总是被告知，在我们开发的任何Java程序中都不能使用'static'，但是当我看到Play时！ ......好吧......大约一半的方法都是静态的。＆LT; /夸张＆GT; 我想，至少，我们可以使用单例对象（通过使用Scala，例如^^）来编程我们的项目，但我非常担心框架本身实际上有多少静态。那么，我应该关注这个吗？玩的方式！开发人员编程使它成为所有这些静态不会造成问题的？（例如，这个主题有一个关于为什么要不惜一切代价避免静态成员的咆哮。）

已邀请:

14 个回复

缝皋

Play只有在有意义时才使用静态方法：在控制器层中，因为控制器不是面向对象的。控制器充当HTTP世界（无状态，基于请求/响应）和完全面向对象的模型层之间的映射器。在工厂方法的模型层中，如findAll（），count（），create（）当然不依赖于任何特定实例在一些提供纯实用函数的play.libs。*类中

藕挝

Play框架不是一个很好的演示，当使用静态时是合适的，也不能证明你的老师是错的。 Play是一种作弊行为，解决了Java语言之外的静态问题。关键问题是你必须并行处理多个HTTP请求，静态字段是“全局的”。因此，对于某些事情，每个线程需要一个实例（甚至更好，每个HTTP请求一个实例），但其中一些实例是由Play中的静态方法返回的。这很有效，因为玩！大量使用ThreadLocal-s，因此它解决了Java语言之外的静态问题。但那不是一切。有人说控制器方法是正确的静态。当然，但是在普通的Java中它会很不方便，因为你不能在没有某种前缀的情况下访问特定于请求的数据，比如req.session在req.session，然后你仍然需要从某个地方获得req，比如作为参数静态控制器方法，这更麻烦。然而在Play中你可以直接写session而且喜欢它们只是静态字段。那是因为Play使用字节码检测将所有静态字段引用更改为更智能的东西。同样，Java语言之外的解决方案。那些不是最后的静态字段。所以，一般来说，避免非最终静态。 Play虽然为你带来了魔力，所以在这种情况下不要害怕它们。

骇毖煽洁铂

从简短的说来看，我认为它有点理由：Web请求是无状态的，因此没有对象接收请求（=方法）。因此，将诸如“/ articles / archive？date = 08/01/08＆amp; page = 2”之类的URI映射到一个名为archive()的静态方法，我想，你的应用程序类是有意义的。

拈吉勉犬姆

编辑现在在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％是静态的，那么我猜它可能设计得很糟糕。那也不例外;很多框架都是。不要让它让你失望。绝对不要向它学习！但如果它有效，你仍然可以使用它。

徐百晴墓斜

主要问题是静态方法只能访问其他静态方法和字段，这导致“静态粘附”，静态方法必须通过公共静态字段与应用程序的其余部分（包含其协作者）会合。，这导致不灵活。免责声明：我不太了解'玩！'

伞腹

静态控制器方法无疑是Play的关注领域！框架，经过一些测试后，这是我不玩Play的主要原因！在项目中。你实际上可以在FOSS项目里看到这里玩的地方！用来。几乎没有控制器测试。原因是，采用静态方法，DI变得困难。这是他们应该花费更多时间使用ASP.NET MVC的地方，从Play！已经需要一些灵感。通常你有一个像这样的构造函数：

public HomeController( IService service ) {
   _service = service;
}
public Index() {
   var data = _service.getData();
   return View( data );
}

然后使用DI将IService实现注入Controller。关键是在测试中，您可以在运行Controller之前实例化IService，然后根据您刚刚生成的IService测试结果。在Play中，这变得非常困难。因此控制器单元测试变得困难。对我来说，这是一个重大问题。因此，我倾向于寻找除Play之外的其他框架！在Java世界中。哎呀，为什么不使用原版并只使用JRuby？

际恃啸称桅

游戏中的静态方法主要用于控制器动作方法。这些方法只是从模型中获取必要数据并将其公开给视图。它们以某种方式对应每个可能的http请求，就像那些http请求完全是无状态的一样。在结构编程上，一方面是程序，另一方面是变量，但在OOP范例中，您将程序和变量视为一个整体。也就是说，您具有实例方法（过程）和实例变量的对象。但控制器操作是无状态的，即它们从请求中获取所有变量（也可能来自缓存，但在这种情况下，您需要某种最终来自请求的会话ID）。因此控制器操作就像状态过程一样，这就是为什么它们不像模型那样特别适合OOP范例。

社攻取墟槽

我想，至少，我们可以使用单例对象 Java中的Singleton与使用所有静态没有多大区别。作为国家也没有多少存储。我想你不应该担心它。那么，我应该关注这个吗？玩的方式！开发人员编程使它成为所有这些静态不会造成问题的？它不会。事实上，没关系。

埃输林桨铃

我也对游戏中静态方法的数量感到惊讶，但为什么不工作呢？其实我不同意你的老师。如果一个对象没有状态（即全局变量）但只包含例子的方法，那么使用对象而不是静态方法不会带来任何好处。除非您计划稍后添加状态（不应共享的状态），或者您正在使用接口并希望能够轻松切换实现，否则使用静态方法会更容易... JDK本身，apache commons或许多框架都包含静态方法： StringUtils的 Pattern.matches（正则表达式，输入） ---------- 其实我猜你想知道像JPA.java这样的类是什么： https://github.com/playframework/play/blob/master/framework/src/play/db/jpa/JPA.java 它们仅使用静态方法并保持静态。这可能很奇怪，但实际上对我来说这有点像使用单例，除了方法用于静态上下文而不是对象。主要区别在于您不必每次都调用getInstance（）。我认为这是为可用性而设计的，因为调用“getInstance”并不是用户友好的，能够轻松地在任何地方（链接到线程）轻松获得会话而不是使用xml或自动装配注入sessionFactory很酷。 .. 您的教授可能会告诉您避免使用静态，因为如果您不正确使用它们，可能会对您的设计造成危险。但请注意，在许多情况下，用单例替换静态方法并不能使您的设计更好。即使您现在在实例方法上调用方法，对象仍然会紧密耦合... 所以也许一个规则应该是避免使用静力学，除非你真的不关心紧耦合。在这种情况下，当您调用JPA.xxx（）方法时，您的代码与play框架的JPA类紧密耦合。但我不认为游戏的设计是为了能够轻松地从一个框架切换到另一个框架而不需要至少一些返工... 这与EJB3规范或类似的东西有很大不同：如果EJB3实体管理器的方法是静态的，那么您将被迫通过调用HibernateEntityManager.xxx（）或ToplinkEntityManager.xxx（）将代码紧密地耦合到实现。在这种情况下，有一个通用接口（我们不能在接口上添加静态方法）。 ---------- 那个班不属于a 其他规格使用构架。 JPA课程刚刚开始一个实现：完成的一个玩。他们可能不是打算做第二个。这样一个紧密耦合到这个Play类，当你使用Play框架时，对我来说似乎没问题。