避免嵌套如果Else / Switches – Java
|
我正在审查一些代码( Java)并根据业务逻辑流程图进行更改.当前的代码依赖于大量的if语句 – 我想尝试并远离它.我一直在阅读有关多态性的文章,并试图围绕如何将其应用于我的情况.我可以使它适用于单个条件级别,但努力在多个条件级别进一步扩展它.代码将在运行时执行,这个’Logic’方法将传递上一步的变量. 受控示例: |----- | 'HOME'
|Place?| ----- > *destination = 'home'*
|----- |
Zoo A | Zoo B
|---------------|----------------------------------------|
|----------| |----------|
|Direction?| |Direction?|
|----------| |----------|
| North | North
----------- *destination = 'Zoo A North' ----------- *destination = 'Zoo B North'
| East | East
----------- *destination = 'Zoo A East' ----------- *destination = 'Zoo B East'
| South | South
----------- *destination = 'Zoo A South' ----------- *destination = 'Zoo B South'
| West | West
----------- *destination = 'Zoo A West' ----------- *destination = 'Zoo B West'
因此,如果人物X有动物园A和南方向,他们应该有一个’动物园A南’的目的地 我使用If语句的代码目前非常难看: if(Place = 'HOME')
destination = 'HOME'
if(Place = 'Zoo A')
if(Direction = North)
destination = 'Zoo A North')
if(Direct = East)
destination = 'Zoo A East')
...
if(Place = 'Zoo B')
if(Direction = North)
destination = 'Zoo B North')
if(Direct = East)
destination = 'Zoo B East')
...
我可以将这个转换为嵌套开关,变量为ENUMs.但我试图避免if – else / switch依赖,因为我有一个不好的习惯.我尝试使用Factory Design来生成Place类,然后在每个位置和目标上使用Polymorphism,但它开始变得过于复杂.是否值得远离if / switches?我只是想过度设计吗? 关于如何处理像这样的逻辑流的任何建议? 解决方法这可以这样建模:>使用方法calculateDestination(Person)的根类Place.地方可以包含其中的其他地方. 现在,您将实例化这些类的对象以表示您的情况: zooA = new Zoo("ZooA");
zooA.addChild(new ZooQuadrant(Direction.SOUTH));
... so on for every quadrant ...
... same for zooB ...
home = new Place("Home");
world = new Place("World");
world.addChild(home);
world.addChild(zooA);
world.addChild(zooB);
当你想要获得目的地时,你会打电话给world.calculateDestination(myPerson) calculateDestination(Person)是多态方法.继承层次结构中的每个级别都将根据该类的特定语义覆盖它. > Place将有一个通用实现,它将测试Person实例当前是否在该节点上(通过对currentPlace的Person值进行测试),如果不是,它将在每个子节点上调用calculateDestination并返回它. 注意:这只是为了说明多态可能如何工作,可能有更好的实现.此外,这里我们使用多态和递归,两者是独立的. 编辑: 至于是否需要增加复杂性,这取决于!在这里,我们使用一个非常小的对象图的简单示例.一旦你拥有数十个动物园,就必须在这些动物园中添加更多象限,或者需要做出额外的决策(如果每个象限都有子参数),嵌套的if-else-if方法(程序)真的得到了毛茸茸的很快,而面向对象的方法仍然是可维护和可理解的. 像所有事情一样,如果您预见决策会变得那么复杂,那么请使用OO方法.否则,保持简单就是每次都能胜过美女:使用合适的工具来解决问题. (编辑:安卓应用网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
