反if运动 - IT宝库

本文是小编为大家收集整理的关于反if运动的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。

中文
English

问题描述

我最近遇到了一个非常有趣的网站，该网站表达了一个非常有趣的想法 - 反假活动.您可以在 www.antiifcampaign.com 上看到此处.我必须同意，如果陈述是后部的绝对疼痛，复杂的嵌套是嵌套的.我目前正在进行一个项目，直到最近才有一些疯狂的嵌套IFS滚动到右边的情况.我们通过两种方式治愈了问题 - 我们使用Windows Workflow Foundation解决了路由(或工作流)的问题.而且，我们正在实施使用.NET的ILOG规则(最近由IBM购买！)实施所有业务规则.这在大多数情况下已经治愈了我们的嵌套……但是我发现自己想知道有多少人以反ficfcampaign的好人的方式治愈自己的痛苦(请参见此处的示例)，通过创建大量的抽象类来表示给定的方案，该场景最初涵盖了该场景嵌套如果.我想知道是否还可以通过使用IOC容器(例如structuremap)进入和移出不同功能的其他方法来解决这种复杂性.无论哪种方式...

问题:给定我有一个嵌套的复合物IF或Switch语句的情况，用于评估给定类型的事物(例如评估枚举)以确定我要如何处理处理枚举类型的那件事 - 在不使用IF或SWITCH层次结构的情况下进行相同形式的处理方式有哪些方法?

public enum WidgetTypes
{
    Type1,
    Type2,
    Type3,
    Type4
}

...

WidgetTypes _myType = WidgetTypes.Type1;

...

switch(_myType)
{
    case WidgetTypes.Type1:
        //do something
        break;

    case WidgetTypes.Type2:
        //do something
        break;

    //etc...
}

其他推荐答案

在Java中，很容易用作多态性抗剂.

public class AntiIf {
    public enum WidgetTypes {
    Type1 {
        public void doSomething() {
        //...
        }},
    Type2 {
        public void doSomething() {
        //...
        }},
    Type3 {
        public void doSomething() {
        //...
        }},
    Type4 {
        public void doSomething() {
        //...
        }};

    public abstract void doSomething();
    }

    WidgetTypes _myType; // set by someone to one of the types.

    public void someFunction() {
    //...
    _myType.doSomething();
    //...
    }
}

其他推荐答案

反对如果是愚蠢的.

有时通过多态性替换有条件的事情是正确的，但是在这种情况下，如果语句是真正的问题，则不是.真正的问题是以非抽象方式使用抽象类型，即未能在基类的抽象级别上考虑.

其他时候，可以通过多态性替换有条件的条件，但是这样做是一个坏主意.导致您处理一种与另一种类型的一种类型的逻辑可能属于算法本身，而不是单个类.将该逻辑移至类可能会导致类的代码过于意识到使用它们的上下文.

但最常见的是，如果语句与多态性无关.如果语句是错误的目标.

反对如果是愚蠢的.

本文地址：https://www.itbaoku.cn/post/627567.html

百度翻译此文有道翻译此文

问题描述

I recently ran against a very interesting site that expresses a very interesting idea — the anti-if campaign. You can see this here at www.antiifcampaign.com. I have to agree that complex nested IF statements are an absolute pain in the rear. I am currently on a project that up until very recently had some crazy nested IFs that scrolled to the right for quite a ways. We cured our issues in two ways - we used Windows Workflow Foundation to address routing (or workflow) concerns. And we are in the process of implementing all of our business rules utilizing ILOG Rules for .NET (recently purchased by IBM!!). This for the most part has cured our nested IF pains...but I find myself wondering how many people cure their pains in the manner that the good folks at the AntiIfCampaign suggest (see an example here) by creating numerous amounts of abstract classes to represent a given scenario that was originally covered by the nested IF. I wonder if another way to address the removal of this complexity might also be in using an IoC container such as StructureMap to move in and out of different bits of functionality. Either way...

Question: Given a scenario where I have a nested complex IF or SWITCH statement that is used to evaluate a given type of thing (say evaluating an Enum) to determine how I want to handle the processing of that thing by enum type - what are some ways to do the same form of processing without using the IF or SWITCH hierarchical structure?

public enum WidgetTypes
{
    Type1,
    Type2,
    Type3,
    Type4
}

...

WidgetTypes _myType = WidgetTypes.Type1;

...

switch(_myType)
{
    case WidgetTypes.Type1:
        //do something
        break;

    case WidgetTypes.Type2:
        //do something
        break;

    //etc...
}

其他推荐答案

In Java it's easy to use enums as polymorphic anti-if agents.

public class AntiIf {
    public enum WidgetTypes {
    Type1 {
        public void doSomething() {
        //...
        }},
    Type2 {
        public void doSomething() {
        //...
        }},
    Type3 {
        public void doSomething() {
        //...
        }},
    Type4 {
        public void doSomething() {
        //...
        }};

    public abstract void doSomething();
    }

    WidgetTypes _myType; // set by someone to one of the types.

    public void someFunction() {
    //...
    _myType.doSomething();
    //...
    }
}

其他推荐答案

Being anti-if is silly.

Sometimes replacing a conditional via polymorphism is the right thing to do, but in those cases it wasn't the if statement that was the true problem. The real problem was working with abstract types in non-abstract ways, i.e., failing to think at level of abstraction of the base class.

Other times it is possible to replace a conditional via polymorphism, but doing so would be a bad idea. The logic that leads you to treat one type different from another may belong in the algorithm itself, not the individual classes. Moving that logic to the classes may cause the classes' code to be overly aware of the context in which they are used.

But most often, an if statement has nothing to do with polymorphism at all. Getting rid of if statements is the wrong goal here.

Being anti-if is silly.

上一篇：与面向对象的设计有关的构图是什么?

下一篇：使用命令设计模式