2010-07-13 141 views
0

我有一个类Response它包含一个HTTP响应与HTTP状态代码像200或404和其他一些东西,如视图名称和域对象。但让我们专注于状态代码。我可以用一个单独的类,并作为参数传递的状态:具有多个构造函数参数值或多个类的单个类?

public class Response { 
    private int status; 
    public Response(int status) { 
    this.status = status; 
    } 
} 

// in a handler method: 

return new Response(HttpStatus.OK); 

另一种方法是创建一个新的类,每状态代码(HTTP 1.1 41个状态码)。就像这样:

public class Ok extends Response { 
    public Ok() { 
    super(HttpStatus.OK); 
    } 
} 

// in a handler method: 
return new Ok(); 


public class Created extends Response { 
    public Created() { 
    super(HttpStatus.CREATED); 
    } 
} 

// in a handler method: 
return new Created(); 

在现实中会出现通常比较参数,如视图名称和域对象,这样new Response(HttpStatus.OK, "customer", customer)各自new Ok("customer", customer)

+1

每个状态代码碰巧有不同的独特处理,或者他们都在做同样的事情,除了他们的#不同吗?如果这些课程没有带来任何新的表格,请不要使用它们。 – 2010-07-13 20:02:57

+0

状态被发送到客户端,但对于服务器端来说,它们非常相似,只有一些与底层servlet API有点不同的错误代码的例外,但这不是该类的责任( es)如上所示。 – deamon 2010-07-13 20:07:48

+0

@大卫 - 这将是一个很好的答案,而不是一个评论。 – Alohci 2010-07-13 20:08:30

回答

0

问问自己 - 你需要不同的“类型”为每一个状态码?例如,如果您想使用特定类型(例如OK)作为某种方法的参数,它可能很有用。如果没有,我认为第二种方法没有任何好处。去第一个。

6

我的建议 1)如果没有与每个状态码相关的行为,则不需要新的抽象。 2)使用枚举常量而不是int

+1

你说得对,枚举更好。我想知道我是否应该允许其他状态码,而不是HTTP 1.1定义的状态码。 – deamon 2010-07-13 20:10:17

+1

定义比特定协议更接近业务域的枚举。如果你觉得它们是协议特定的,并且仍然需要它们,那么你不应该定义新的枚举常量,并把它们看作与HTTP OK一样。 – 2010-07-13 22:40:45

0

我会保持构造器简单。喜欢的东西:

public Response(int status) 
public Response(int status, String reasonPhrase) 
public Response(int status, Map<String,String> headers) 
public Response(int status, String reasonPhrase, Map<String,String> headers) 

,或者可能省略最后2并提供setHeader(String, String)

1

“纯”的方式是为每个不同的值设置一个类型,但实际上这可能是矫枉过正的。

一般来说,考虑是否:

  • 有任何独特的处理(其适合以班级)

  • 是否有可能是实体之间的分级(例如,状态代表成功和状态代表错误)。

根据我的经验,如果域中有层次结构,他们通常会在代码中结束。您可以通过围绕这个计划来保存未来的重构。例如,错误状态可能稍后也会包含诸如错误细节等问题。

我的经验法则是查看幻数出现的规格。如果它们每个都与很多细节相关联,那么如果仅仅将它们作为整数,这可能表示未来的问题,因为我基本上是使用一个更复杂实体的关键。

此外,从固定域获取细节时,枚举可能会比直接int更好。

相关问题