Java - 解决多个条件逻辑的设计模式

rhe*_*ser 4 java design-patterns strategy-pattern

假设我有一个实用程序类。在本课程中,我仅公开 2 个公共函数:

\n\n
public static boolean checkCustomerEligiblity(HttpServletRequest request)\npublic static boolean checkCartEligiblity(HttpServletRequest request)\n
Run Code Online (Sandbox Code Playgroud)\n\n

这些方法\xe2\x80\x99s的实现真的很乱(我没有实现这个方法)。为了供将来参考,我想了解在这种情况下我们可以实施的最佳方法。

\n\n

还要记住的是,如果条件为 FALSE,我们不应该退出或返回。我们必须记录 FALSE 条件并给出原因,然后继续进行其余的检查。

\n\n
public static Boolean checkCustomerEligiblity(HttpServletRequest request) {\n      if (Flags) { //Check if Flags are ON, only then proceed with rest         \n        if (Type of customer) { //Restrict only to certain type of customers\n          if (Customer within limit) { //Check customer\xe2\x80\x99s available cash limit in account\n\n          } else reasons.add(\xe2\x80\x9cCustomer not within limit\xe2\x80\x9d);\n        } else reasons.add(\xe2\x80\x9cCustomer type not supported\xe2\x80\x9d);\n\n        if (Customer account is NULL) {\xe2\x80\xa6}\n        if (Customer skipped verification with photo ID) {\xe2\x80\xa6}\n        if (Customer\xe2\x80\x99s organization has opted in the plan) {\xe2\x80\xa6}\n        if (Customer\xe2\x80\x99s bill is combined bill) {\xe2\x80\xa6}\n        if (Customer has past due on his account) {\xe2\x80\xa6}\n        if (Customer\xe2\x80\x99s credit rating is good) {\xe2\x80\xa6}\n        if (Customer\xe2\x80\x99s account is active) {\xe2\x80\xa6}\n        if (Customer has not opted for this plan already) {\xe2\x80\xa6}\n\n        ...around 15-20 If conditions more...\n      }\n}\n
Run Code Online (Sandbox Code Playgroud)\n\n

checkCartEligibility() 方法具有相同的结构。

\n\n

我的问题是 \xe2\x80\x93

\n\n

1)使用Strategy或Command设计模式来实现上述功能会不会太笨重?

\n\n

例如,

\n\n
public interface Validator {\n   Boolean validate(HttpServletRequest);\n}\n\npublic class CustomerCreditValidator implements Validator {\xe2\x80\xa6}\npublic class FlagValidator implements Validator {\xe2\x80\xa6}\npublic class AccountVerificationValidator implements Validator {\xe2\x80\xa6}\npublic class OrderTypeValidator implements Validator {\xe2\x80\xa6}\npublic class CartValidator implements Validator {\xe2\x80\xa6}\n
Run Code Online (Sandbox Code Playgroud)\n\n

\xe2\x80\xa6so 还有大约 10-15 个验证器类(我可以在同一类中组合几个检查来减少此类类的数量)。

\n\n
List<Validator> validators = new ArrayList<>();\n\nvalidators.add(new CustomerCreditValidator());  \nvalidators.add(new FlagValidator());\nvalidators.add(new AccountVerificationValidator());\nvalidators.add(new OrderTypeValidator());\nvalidators.add(new CartValidator());`\n
Run Code Online (Sandbox Code Playgroud)\n\n

\xe2\x80\xa6so 用于其他类。

\n\n
for (Validator validator : validators) {\n   boolean result = validator.validate(request);\n   if (result) {\n      ...\n}\n
Run Code Online (Sandbox Code Playgroud)\n\n

2)如果上述方法也太麻烦,您建议实现上述逻辑的其他设计模式是什么?

\n\n

3)顺便说一句,每个验证检查都是私有的,所以我可以将所有上述验证器类仅作为内部类吗?

\n\n

非常感谢任何帮助!

\n

Joh*_*ger 5

策略和命令等设计模式旨在解决松散耦合组件的问题。这对于代码重用是有利的,并且对于可以容易地添加新特征或容易修改现有特征的设计来说可能是有利的。然而,这些模式对于一般的代码组织来说并不是特别有用,因为没有预期到这种需求。

使用策略或命令设计模式来实现上述功能会不会太笨重?

看起来这确实会比你现在拥有的代码多得多,当然还有更多单独的类,以及一些你现在根本不需要的粘合代码。假设所有新课程都是一次性的(情况很可能如此),我不能说我看到了任何吸引力。

如果上述方法也太麻烦,您会建议实现上述逻辑的其他设计模式是什么?

我认为这种情况不一定需要命名模式,而只是为了更好的风格。特别是,我会考虑将每个单独的检查编写为单独的私有方法,而不将其包装在自己的类中。然后,公共检查器方法将大部分甚至全部由各个检查方法的一系列调用组成。

顺便说一句,每个验证检查都是私有的,所以我可以将上述所有验证器类仅作为内部类吗?

如果您确实使用验证器类,那么您可以将这些类设为私有嵌套类,是的,无论是内部类还是静态嵌套类。但你现在提出的情况对我来说更加表明这种方法是矫枉过正的。首先尝试将其分解为多种方法。