gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 06:48:34 24 4
gpt4 key购买 nike

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

public static boolean checkCustomerEligiblity(HttpServletRequest request)
public static boolean checkCartEligiblity(HttpServletRequest request)

每个方法的实现都非常困惑(我没有实现这个方法)。为了供将来引用,我想了解在这种情况下我们可以实现的最佳方法。

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

public static Boolean checkCustomerEligiblity(HttpServletRequest request) {
if (Flags) { //Check if Flags are ON, only then proceed with rest
if (Type of customer) { //Restrict only to certain type of customers
if (Customer within limit) { //Check customer’s available cash limit in account

} else reasons.add(“Customer not within limit”);
} else reasons.add(“Customer type not supported”);

if (Customer account is NULL) {…}
if (Customer skipped verification with photo ID) {…}
if (Customer’s organization has opted in the plan) {…}
if (Customer’s bill is combined bill) {…}
if (Customer has past due on his account) {…}
if (Customer’s credit rating is good) {…}
if (Customer’s account is active) {…}
if (Customer has not opted for this plan already) {…}

...around 15-20 If conditions more...
}
}

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

我的问题是 -

1)使用策略或命令设计模式来实现上述内容会不会太笨重?

例如,

public interface Validator {
Boolean validate(HttpServletRequest);
}

public class CustomerCreditValidator implements Validator {…}
public class FlagValidator implements Validator {…}
public class AccountVerificationValidator implements Validator {…}
public class OrderTypeValidator implements Validator {…}
public class CartValidator implements Validator {…}

…等等,还有大约 10-15 个 validator 类(我可以在同一类中结合几个检查来减少此类类的数量)。

List<Validator> validators = new ArrayList<>();

validators.add(new CustomerCreditValidator());
validators.add(new FlagValidator());
validators.add(new AccountVerificationValidator());
validators.add(new OrderTypeValidator());
validators.add(new CartValidator());`

...其他类(class)依此类推。

for (Validator validator : validators) {
boolean result = validator.validate(request);
if (result) {
...
}

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

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

非常感谢任何帮助!

最佳答案

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

Will it be too unwieldy to use Strategy or Command design pattern to implement the above?

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

If the above approach is going to be too cumbersome too, what is/are the other design pattern(s) would you propose the implement the above logic?

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

By the way, each of the validation checks are private, so can I have all the above validator classes as inner classes only?

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

关于Java - 解决多个条件逻辑的设计模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41601354/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com