问题描述
我有一个如果不久的将来可能会增长的其他陈述.
public void decide(String someCondition){ if(someCondition.equals("conditionOne")){ // someMethod("someParameter"); }else if(someCondition.equals("conditionTwo")){ // someMethod("anotherParameter"); } . . else{ someMethod("elseParameter"); } }
以来,这已经看起来很混乱,我认为如果我可以在这里应用任何设计模式,那会更好.我研究了策略模式,但我不确定如果这里有其他条件,这是否会减少.有任何建议吗?
推荐答案
这是经典的替代条件调度员与命令图案书.
基本上,您为您的旧代码中的每个代码块制作Command对象
interface Handler{ void handle( myObject o); } Map<String, Handler> commandMap = new HashMap<>(); //feel free to factor these out to their own class or //if using Java 8 use the new Lambda syntax commandMap.put("conditionOne", new Handler(){ void handle(MyObject o){ //get desired parameters from MyObject and do stuff } }); ...
然后,而不是您的if/else代码,而是:
commandMap.get(someCondition).handle(this);
现在,如果您需要以后添加新命令,则只需添加到哈希.
如果要处理默认情况,则可以使用Null Object模式来处理条件不在地图中的情况.
Handler defaultHandler = ... if(commandMap.containsKey(someCondition)){ commandMap.get(someCondition).handle(this); }else{ defaultHandler.handle(this); }
其他推荐答案
让我们假设我们有这样的代码(与您的代码相同):
public void decide(String someCondition) { if(someCondition.equals("conditionOne")) { someMethod("someParameter"); } else if(someCondition.equals("conditionTwo")) { someMethod("anotherParameter"); } else { someMethod("elseParameter"); } }
假设您不想重构应用程序的其他部分,并且您不想更改方法签名.
警告 - 您应该使用上述模式的通用版本.
我展示了非通用的,因为阅读它们更容易.
策略 +工厂方法
我们可以使用策略和工厂方法模式.我们还利用了多态性.
private final StrategyConditionFactory strategyConditionFactory = new StrategyConditionFactory(); public void decide(String someCondition) { Strategy strategy = strategyConditionFactory.getStrategy(someCondition) .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); strategy.apply(); }
最好以工厂中包含其他条件的方式进行设计,开发人员故意将其称为.在这种情况下,当不满足条件时,我们会引发例外.另外,我们可以按照疑问的方式编写它.如果需要,而不是.orElseThrow(() -> new IllegalArgumentException("Wrong condition")); put .orElse(new ElseStrategy());
strategyconditionFactory(工厂方法):
public class StrategyConditionFactory { private Map<String, Strategy> conditions = new HashMap<>(); public StrategyConditionFactory() { conditions.put("conditionOne", new ConditionOneStrategy()); conditions.put("conditionTwo", new ConditionTwoStrategy()); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new ElseStrategy()); //... } public Optional<Strategy> getStrategy(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
策略接口:
public interface Strategy { void apply(); }
实施:
public class ConditionOneStrategy implements Strategy { @Override public void apply() { //someMethod("someParameter"); } }
public class ConditionTwoStrategy implements Strategy { @Override public void apply() { //someMethod("anotherParameter") } }
public class ElseStrategy implements Strategy { @Override public void apply() { //someMethod("elseParameter") } }
用法(简化):
public void strategyFactoryApp() { //... decide("conditionOne"); decide("conditionTwo"); decide("conditionElse"); //... }
策略 +工厂方法 - 这种特殊情况(只有参数更改)
我们可以使用以下事实:在这种情况下,我们始终调用相同的方法,只有参数更改
我们使用GetParameter()方法将基本策略接口更改为抽象类,并为此抽象类做出了新的实现.其他代码保持不变.
public abstract class Strategy { public abstract String getParameter(); public void apply() { someMethod(getParameter()); } private void someMethod(String parameter) { //someAction } }
实施:
public class CondtionOneStrategy extends Strategy { @Override public String getParameter() { return "someParameter"; } }
public class CondtionTwoStrategy extends Strategy { @Override public String getParameter() { return "anotherParameter"; } }
public class ElseStrategy extends Strategy { @Override public String getParameter() { return "elseParameter"; } }
枚举 +枚举"工厂"
我们可能会使用枚举来实施策略,而不是工厂方法,我们可以从Enum中使用ValueOf().
public void decide(String someCondition) { ConditionEnum conditionEnum = ConditionEnum.valueOf(someCondition); conditionEnum.apply(); }
条件枚举:
public enum ConditionEnum { CONDITION_ONE { @Override public void apply() { //someMethod("someParameter"); } }, CONDITION_TWO { @Override public void apply() { //someMethod("anotherParameter"); } }, CONDITION_ELSE { @Override public void apply() { //someMethod("elseParameter"); } }; //...more conditions public abstract void apply(); }
用法(简化):
public void enumFactoryApp() { //... decide("CONDITION_ONE"); decide("CONDITION_TWO"); decide("CONDITION_ELSE"); //... }
请注意,当指定名称没有常数时,您将获得IllegalArgumentException.
命令 +工厂
策略和命令之间的区别在于命令也要说明,因此,如果您有计算(int a,int b,string somecontition),并且您想用策略对其进行重新分配,包括签名更改,您可以将其减少到计算(int) a,int b,computestgy computestgy)带有命令,您可以将其简化为一个参数计算(ComputeCommand Computecommand).在这种情况下,我们还利用了类似于策略模式案例的多态性.
CommandConditionFactory commandConditionFactory = new CommandConditionFactory(); public void decide(String someCondition) { Command command = commandConditionFactory.getCommand(someCondition) .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); command.apply(); }
最好以工厂中包含其他条件的方式进行设计,开发人员故意将其称为.在这种情况下,当不满足条件时,我们会引发例外.另外,我们可以按照疑问的方式编写它.如果您需要的话,而不是.orElseThrow(() -> new IllegalArgumentException("Wrong condition")); put .orElse(new ElseCommand());
CommandConditionFactory(工厂方法):
public class CommandConditionFactory { private Map<String, Command> conditions = new HashMap<>(); public CommandConditionFactory() { conditions.put("conditionOne", new ConditionOneCommand("someParameter")); conditions.put("conditionTwo", new ConditionTwoCommand("anotherParameter")); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new ElseCommand("elseParameter")); //... } public Optional<Command> getCommand(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
命令接口:
public interface Command { void apply(); }
实现(有一些冗余,但是在更普遍的情况下,在那里表明命令应该如何看待,而不是somemethod()我们有三种不同的方法):
public class ConditionOneCommand implements Command { private final String parameter; public ConditionOneCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
public class ConditionTwoCommand implements Command { private final String parameter; public ConditionTwoCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
public class ElseCommand implements Command { private final String parameter; public ElseCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
用法(简化):
public void commandFactoryApp() { //... decide("conditionOne"); decide("conditionTwo"); decide("conditionElse"); //... }
命令 +工厂 - 这种特殊情况.
实际上,这并不是真正的命令模式.它利用了一个事实,在这种情况下,我们总是在调用相同的方法somemethod(参数),并且只有参数更改.
摘要类:
public abstract class Command { abstract void apply(); protected void someMethod(String parameter) { //someAction } }
实施(所有3种条件案例相同):
public class CommandImpl extends Command { private final String parameter; public CommandImpl (String parameter) { this.parameter = parameter; } @Override public void apply(){ someMethod(parameter); } }
工厂,请注意,只有一个命令实现,只有参数更改:
public class CommandConditionFactory { Map<String, Command> conditions = new HashMap<>(); public CommandConditionFactory() { conditions.put("conditionOne", new CommandImpl("someParameter")); conditions.put("conditionTwo", new CommandImpl("anotherParameter")); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new CommandImpl("elseParameter")); //... } public Optional<Command> getCommand(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
如果是
请注意,即使您有时嵌套了IF,也可以重构它们并使用提到的技术之一.
可以说,我们有以下代码:
public void decide2(String someCondition, String nestedCondition) { if(someCondition.equals("conditionOne")) { if(nestedCondition.equals("nestedConditionOne")){ someLogic1(); } else if(nestedCondition.equals("nestedConditionTwo")){ someLogic2(); } } else if(someCondition.equals("conditionTwo")) { if(nestedCondition.equals("nestedConditionThree")){ someLogic3(); } else if(nestedCondition.equals("nestedConditionFour")){ someLogic4(); } } }
您可以使用数学逻辑规则进行重构:
public void decide2(String someCondition, String nestedCondition) { if(someCondition.equals("conditionOne") && nestedCondition.equals("nestedConditionOne")) { someLogic1(); } else if(someCondition.equals("conditionOne") && nestedCondition.equals("nestedConditionTwo")) { someLogic2(); } else if(someCondition.equals("conditionTwo") && nestedCondition.equals("nestedConditionThree")) { someLogic3(); } else if(someCondition.equals("conditionTwo") && nestedCondition.equals("nestedConditionFour")) { someLogic4(); } }
然后您可以使用策略,枚举或命令.您只有一对字符串<字符串,字符串>而不是单字符串.
决策表
当您嵌套不可重复的IF时,您可以实现自己的决策表或使用一些准备好的决策表解决方案.我不会在那里实施.
规则引擎
当您嵌套不可重复的IF时,您还可以实现自己的简单规则引擎.仅当您有很多嵌套IF时,才应该使用它,否则它是表格的胜利.
对于非常复杂的商业逻辑,有一些专业的规则引擎,例如Drools.
我不会在那里实施.
另外一件事
在您给出的示例中,有人很有可能引入这些IF,但它们是完全多余的.我们可以通过试图重构决定方法签名来检查它,以使其采取其他论点,并重构围绕着我们方法的代码.通过这样做,我们将摆脱我们的工厂方法.有一些示例显示了当代码发生时的外观,这些IF是多余的.
策略
决定方法:
public void decide(Strategy strategy) { strategy.apply(); }
用法(简化):
public void strategyApp() { //... decide(new ConditionOneStrategy()); decide(new ConditionTwoStrategy()); decide(new ElseStrategy()); //... }
枚举
决定方法:
public void decide(ConditionEnum conditionEnum) { conditionEnum.apply(); }
用法(简化):
public void enumApp() { //... decide(ConditionEnum.CONDITION_ONE); decide(ConditionEnum.CONDITION_TWO); decide(ConditionEnum.CONDITION_ELSE); //... }
命令
决定方法:
public void decide(Command command) { command.apply(); }
用法(简化):
public void commandApp() { //... decide(new ConditionOneCommand("someParameter")); decide(new ConditionTwoCommand("anotherParameter")); decide(new ElseCommand("elseParameter")); //... }
实际上是非常具体的情况,例如,在某些情况下,我们必须使用诸如字符串之类的简单类型,因为它来自外部系统或条件是基于输入的整数,因此我们无法重构代码如此轻松.
其他推荐答案
马丁·福勒(Martin Fowler)的一般建议是 用多态性代替有条件的.
.在设计模式方面,这通常是策略模式 用策略代替条件逻辑.
.如果您的条件有限,有限的,我建议使用 enum 实施策略模式(在枚举中提供抽象方法并覆盖它对于每个常数).
public enum SomeCondition{ CONDITION_ONE{ public void someMethod(MyClass myClass){ //... } }, CONDITION_TWO{ public void someMethod(MyClass myClass){ } } public abstract void someMethod(MyClass myClass); } public class MyClass{ //... public void decide(SomeCondition someCondition){ someCondition.someMethod(this); } }
如果实际上只是您要选择的参数,那么您可以定义这样的枚举:
public enum SomeCondition{ CONDITION_ONE("parameterOne"), CONDITION_TWO("parameterTwo"); private final String parameter; private SomeCondition(String parameter){ this.parameter = parameter; } public String getParameter(){ return parameter; } } public class MyClass{ //... public void decide(SomeCondition someCondition){ someMethod(someCondition.getParameter()); } }
问题描述
I have a if else statement which might grow in the near future.
public void decide(String someCondition){ if(someCondition.equals("conditionOne")){ // someMethod("someParameter"); }else if(someCondition.equals("conditionTwo")){ // someMethod("anotherParameter"); } . . else{ someMethod("elseParameter"); } }
Since, this is already looking messy, I think it would be better if I can apply any design patterns here. I looked into Strategy pattern but I am not sure if that will reduce if else condition here. Any suggestions?
推荐答案
This is a classic Replace Condition dispatcher with Command in the Refactoring to Patterns book.
Basically you make a Command object for each of the blocks of code in your old if/else group and then make a Map of those commands where the keys are your condition Strings
interface Handler{ void handle( myObject o); } Map<String, Handler> commandMap = new HashMap<>(); //feel free to factor these out to their own class or //if using Java 8 use the new Lambda syntax commandMap.put("conditionOne", new Handler(){ void handle(MyObject o){ //get desired parameters from MyObject and do stuff } }); ...
Then instead of your if/else code it is instead:
commandMap.get(someCondition).handle(this);
Now if you need to later add new commands, you just add to the hash.
If you want to handle a default case, you can use the Null Object pattern to handle the case where a condition isn't in the Map.
Handler defaultHandler = ... if(commandMap.containsKey(someCondition)){ commandMap.get(someCondition).handle(this); }else{ defaultHandler.handle(this); }
其他推荐答案
Let's assume that we have such code (which is the same as yours):
public void decide(String someCondition) { if(someCondition.equals("conditionOne")) { someMethod("someParameter"); } else if(someCondition.equals("conditionTwo")) { someMethod("anotherParameter"); } else { someMethod("elseParameter"); } }
Assuming that you don't want to refactor other parts of the application and you don't want to change method signature there are possible ways in which it could be refactored:
Warning - You should use generic versions of mentioned patterns.
I showed non generic ones because it is easier to read them.
Strategy + Factory Method
We can use Strategy and Factory Method patterns. We also take advantage of polymorphism.
private final StrategyConditionFactory strategyConditionFactory = new StrategyConditionFactory(); public void decide(String someCondition) { Strategy strategy = strategyConditionFactory.getStrategy(someCondition) .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); strategy.apply(); }
It would be better to design it in a way that else condition is included in the factory, and developer calls it on purpose. In such case we throw exception when condition is not meet. Alternatively we could write it exactly as it was in question. If you want so instead of .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); put .orElse(new ElseStrategy());
StrategyConditionFactory (factory method):
public class StrategyConditionFactory { private Map<String, Strategy> conditions = new HashMap<>(); public StrategyConditionFactory() { conditions.put("conditionOne", new ConditionOneStrategy()); conditions.put("conditionTwo", new ConditionTwoStrategy()); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new ElseStrategy()); //... } public Optional<Strategy> getStrategy(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
Strategy interface:
public interface Strategy { void apply(); }
Implementations:
public class ConditionOneStrategy implements Strategy { @Override public void apply() { //someMethod("someParameter"); } }
public class ConditionTwoStrategy implements Strategy { @Override public void apply() { //someMethod("anotherParameter") } }
public class ElseStrategy implements Strategy { @Override public void apply() { //someMethod("elseParameter") } }
Usage (simplified):
public void strategyFactoryApp() { //... decide("conditionOne"); decide("conditionTwo"); decide("conditionElse"); //... }
Strategy + Factory Method - this particular case (where only parameter changes)
We can use the fact that in this case we always call the same method, only parameter changes
We change our base strategy interface to abstract class with getParameter() method and we make new implementations of this abstract class. Other code remains the same.
public abstract class Strategy { public abstract String getParameter(); public void apply() { someMethod(getParameter()); } private void someMethod(String parameter) { //someAction } }
Implementations:
public class CondtionOneStrategy extends Strategy { @Override public String getParameter() { return "someParameter"; } }
public class CondtionTwoStrategy extends Strategy { @Override public String getParameter() { return "anotherParameter"; } }
public class ElseStrategy extends Strategy { @Override public String getParameter() { return "elseParameter"; } }
Enum + enum kinda "factory"
We might use Enum to implement strategy and instead of factory method we can use valueOf() from enum.
public void decide(String someCondition) { ConditionEnum conditionEnum = ConditionEnum.valueOf(someCondition); conditionEnum.apply(); }
Condition enum:
public enum ConditionEnum { CONDITION_ONE { @Override public void apply() { //someMethod("someParameter"); } }, CONDITION_TWO { @Override public void apply() { //someMethod("anotherParameter"); } }, CONDITION_ELSE { @Override public void apply() { //someMethod("elseParameter"); } }; //...more conditions public abstract void apply(); }
Usage (simplified):
public void enumFactoryApp() { //... decide("CONDITION_ONE"); decide("CONDITION_TWO"); decide("CONDITION_ELSE"); //... }
Notice that you will get IllegalArgumentException when enum type has no constant with the specified name.
Command + Factory
The difference between strategy and command is that command holds also state, so if you have for example compute(int a, int b, String someCondition) and you want to refactor it with strategy including it's signature change you can reduce it to compute(int a, int b, ComputeStrategy computeStrategy) with command you can reduce it to one argument compute(ComputeCommand computeCommand). In this case we also take advantage of polymorphism similarly to strategy pattern case.
CommandConditionFactory commandConditionFactory = new CommandConditionFactory(); public void decide(String someCondition) { Command command = commandConditionFactory.getCommand(someCondition) .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); command.apply(); }
It would be better to design it in a way that else condition is included in the factory, and developer calls it on purpose. In such case we throw exception when condition is not meet. Alternatively we could write it exactly as it was in question. If you want so instead of .orElseThrow(() -> new IllegalArgumentException("Wrong condition")); put .orElse(new ElseCommand());
CommandConditionFactory (factory method):
public class CommandConditionFactory { private Map<String, Command> conditions = new HashMap<>(); public CommandConditionFactory() { conditions.put("conditionOne", new ConditionOneCommand("someParameter")); conditions.put("conditionTwo", new ConditionTwoCommand("anotherParameter")); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new ElseCommand("elseParameter")); //... } public Optional<Command> getCommand(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
Command interface:
public interface Command { void apply(); }
Implementations (there is some redundancy, but It is there to show how command should look in more general case where instead of someMethod() we have three different methods):
public class ConditionOneCommand implements Command { private final String parameter; public ConditionOneCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
public class ConditionTwoCommand implements Command { private final String parameter; public ConditionTwoCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
public class ElseCommand implements Command { private final String parameter; public ElseCommand(String parameter) { this.parameter = parameter; } @Override public void apply() { //someMethod(parameter); } }
Usage (simplified):
public void commandFactoryApp() { //... decide("conditionOne"); decide("conditionTwo"); decide("conditionElse"); //... }
Command + Factory - This particular case.
This in fact isn't a real command pattern just a derivative. It takes advantage of the fact that in this case we are always calling the same method someMethod(parameter) and only the parameter changes.
Abstract class:
public abstract class Command { abstract void apply(); protected void someMethod(String parameter) { //someAction } }
Implementation (the same for all 3 conditional cases):
public class CommandImpl extends Command { private final String parameter; public CommandImpl (String parameter) { this.parameter = parameter; } @Override public void apply(){ someMethod(parameter); } }
Factory, please notice that there is only one command implementation, only parameter changes:
public class CommandConditionFactory { Map<String, Command> conditions = new HashMap<>(); public CommandConditionFactory() { conditions.put("conditionOne", new CommandImpl("someParameter")); conditions.put("conditionTwo", new CommandImpl("anotherParameter")); //It is better to call else condition on purpose than to have it in the conditional method conditions.put("conditionElse", new CommandImpl("elseParameter")); //... } public Optional<Command> getCommand(String condition) { return Optional.ofNullable(conditions.get(condition)); } }
Nested if's
Note that even if you have nested ifs sometimes it is possible to refactor them and use one of the mentioned techniques.
Lets say that we have following code:
public void decide2(String someCondition, String nestedCondition) { if(someCondition.equals("conditionOne")) { if(nestedCondition.equals("nestedConditionOne")){ someLogic1(); } else if(nestedCondition.equals("nestedConditionTwo")){ someLogic2(); } } else if(someCondition.equals("conditionTwo")) { if(nestedCondition.equals("nestedConditionThree")){ someLogic3(); } else if(nestedCondition.equals("nestedConditionFour")){ someLogic4(); } } }
You could refactor it using mathematical logic rules:
public void decide2(String someCondition, String nestedCondition) { if(someCondition.equals("conditionOne") && nestedCondition.equals("nestedConditionOne")) { someLogic1(); } else if(someCondition.equals("conditionOne") && nestedCondition.equals("nestedConditionTwo")) { someLogic2(); } else if(someCondition.equals("conditionTwo") && nestedCondition.equals("nestedConditionThree")) { someLogic3(); } else if(someCondition.equals("conditionTwo") && nestedCondition.equals("nestedConditionFour")) { someLogic4(); } }
and then you can use strategy, enum or command. You just have a pair of Strings <String, String> instead of single String.
Decision Tables
When you have nested ifs that couldn't be refactored as mentioned you can implement your own decision tables or use some ready to go decision tables solution. I won't give the implementation there.
Rules Engine
When you have nested ifs that couldn't be refactored as mentioned you can also implement your own simple rules engine. You should use it only if you have many nested ifs, otherwise it is triumph of form over content.
For very complicated Business Logic there are professional Rule Engines like Drools.
I won't give the implementation there.
One more thing
In the example that you gave there is a high possibility that someone introduced these ifs, but they are totally redundant. And we can check it by trying to refactor decide method signature to make it take some other argument and to refactor surrounding code that is calling our method. By doing so we are getting rid of our Factory Method. There are examples that present how the code might look when it occurs that these ifs were redundant.
Strategy
Decide method:
public void decide(Strategy strategy) { strategy.apply(); }
Usage (simplified):
public void strategyApp() { //... decide(new ConditionOneStrategy()); decide(new ConditionTwoStrategy()); decide(new ElseStrategy()); //... }
Enum
Decide method:
public void decide(ConditionEnum conditionEnum) { conditionEnum.apply(); }
Usage (simplified):
public void enumApp() { //... decide(ConditionEnum.CONDITION_ONE); decide(ConditionEnum.CONDITION_TWO); decide(ConditionEnum.CONDITION_ELSE); //... }
Command
Decide method:
public void decide(Command command) { command.apply(); }
Usage (simplified):
public void commandApp() { //... decide(new ConditionOneCommand("someParameter")); decide(new ConditionTwoCommand("anotherParameter")); decide(new ElseCommand("elseParameter")); //... }
In fact it is quite specific case, there are cases in which for example we have to use simple type like String, because it comes from the external system or condition is based on integer from input so we can't refactor the code so easily.
其他推荐答案
The general recommendation by Martin Fowler is to Replace Conditional with Polymorphism.
In terms of design patterns this would often be the Strategy Pattern Replace Conditional Logic with Strategy.
If you have a small, finite set of conditions, I recommend to use an enum to implement the Strategy Pattern (provide an abstract method in the enum and override it for each constant).
public enum SomeCondition{ CONDITION_ONE{ public void someMethod(MyClass myClass){ //... } }, CONDITION_TWO{ public void someMethod(MyClass myClass){ } } public abstract void someMethod(MyClass myClass); } public class MyClass{ //... public void decide(SomeCondition someCondition){ someCondition.someMethod(this); } }
If it's really just a parameter you want to pick, then you could define the enum like this instead:
public enum SomeCondition{ CONDITION_ONE("parameterOne"), CONDITION_TWO("parameterTwo"); private final String parameter; private SomeCondition(String parameter){ this.parameter = parameter; } public String getParameter(){ return parameter; } } public class MyClass{ //... public void decide(SomeCondition someCondition){ someMethod(someCondition.getParameter()); } }