c#重构注意事项

本文关键字：注意事项 重构 | 更新日期: 2023-09-27 18:11:23

我有以下疑问:

对于重构，我读到创建具有非常具体职责的方法是很好的，所以如果可能的话，将一个复杂的方法拆分为其他小方法是一个好主意。

但是假设我有这种情况:

我必须创建一个对象列表，在这个对象中，我必须创建另一个对象。像这样:

public void myComplexMethod(List<MyTypeA> paramObjectsA)
{
    foreach(MyTypeA iteratorA in paramObjectsA)
    {
        //Create myObjectB of type B
        //Create myObjectC of type C
        myObjectB.MyPorpertyTpyeC = myObjectC;
    }
}

我可以把这个方法分成两个方法。

public void myMethodCreateB(List<MyTypeA> paramObjectsA)
{
    foreach(MyTypeA iteratorA in paramObjectsA)
    {
        //Create myObjectB of type B
    }
}

public void myMethodCreateB(List<MyTypeB> paramObjectsB)
{
    foreach(MyTypeB iteratorB in paramObjectsB)
    {
        //Create myObjectC of type C
        iteratorB.PropertyC = myObjectC;
    }
}

在第二个选项中，当我使用两个方法而不是一个方法时，单元测试就不那么复杂了，但问题是我使用了两个foreach循环，所以它比在第一个选项中只使用一个循环效率要低。

那么，最佳实践是什么，至少在一般情况下，使用更复杂的方法来提高效率还是使用更多的方法?

c#重构注意事项

我通常将可读性置于比性能更高的优先级，除非事实证明并非如此。我现在稍微概括一下，但根据我的经验，当人们过多地关注代码级别的性能时，结果是代码的可维护性较差，这会分散他们创建功能正确的代码的注意力，这需要更长的时间(=更多的钱)，并且可能导致更低性能的代码。

所以不用担心，使用更可读的方法。如果你的应用最后真的太慢了，那就运行一个分析器，找出(并证明)一两个需要优化的地方。我可以向你保证不会是这段代码。

尽早在架构层面做出正确的选择是至关重要的，因为一旦你的应用构建完成，你就不能轻易地在这个层面做出改变。

在这种情况下，我通常会继续使用一个for循环。似乎你只是创建和装饰MyTypeB的对象。我更喜欢在MyTypeB类中创建一个工厂方法:

static MyTypeB Create(MyTypeA a) { // if the creation of MyTypeB depends on A
    //Create myObjectB of type B
    //Create myObjectC of type C
    myObjectB.MyPorpertyTpyeC = myObjectC;
    return myObjectB;
}

那么你的复杂方法将变成:

public void myComplexMethod(List<MyTypeA> paramObjectsA)
{
    foreach(MyTypeA iteratorA in paramObjectsA)
    {
        MyTypeB myObjectB = MyTypeB.Create(iteratorA);
    }
}
相关文章：