避免嵌套如果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方法.否则,保持简单就是每次都能胜过美女:使用合适的工具来解决问题. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |