我有两个按钮,每个按钮可以执行两种不同的实现(无论是否选择),所以总共有 4 种可能的实现。全部编码后,我注意到每个实现都有 20 多行代码,每个实现只有 1 或 2 个变量不同。我决定要清理它并让每个实现调用单独的较小方法并将不一致的变量作为参数传递。
我认为这是一个更好的实践 b/c 我正在重用代码。但是,在我的一种方法中,我必须通过 5 个不同的参数以正确的条件实现该方法。
在方法中有这么多参数是不好的做法吗?
我有两个按钮,每个按钮可以执行两种不同的实现(无论是否选择),所以总共有 4 种可能的实现。全部编码后,我注意到每个实现都有 20 多行代码,每个实现只有 1 或 2 个变量不同。我决定要清理它并让每个实现调用单独的较小方法并将不一致的变量作为参数传递。
我认为这是一个更好的实践 b/c 我正在重用代码。但是,在我的一种方法中,我必须通过 5 个不同的参数以正确的条件实现该方法。
在方法中有这么多参数是不好的做法吗?
拥有许多参数并不是一件坏事。
有一些模式可以创建一个类来将所有参数分组到一个对象中,这对您来说可能看起来更清晰。另一种选择是使用带有所有参数的字典作为单个配置参数。一些 Apple 类会这样做(例如导航栏中的标题字体配置)。
我个人会说代码重复比许多相互调用并具有多个参数的方法更糟糕。
如果它允许您删除许多重复的行,我认为这样做没有任何问题。如果要删除 1 或 2 行,那么它可能不值得努力。
事实上,您可以根据需要传递尽可能多的参数。可能还有其他方法可以完成您要实现的目标,但如果没有代码,您的 5 个参数乍一看似乎是有效的。
没有特定数量的参数通常是“不好的做法”。一个方法应该有尽可能多的参数。也就是说,在某些情况下,具有大量参数可能表明更好的设计是可能的。例如,在某些情况下,您可能会意识到对象应该跟踪成员变量中的某个值,而不是每次都将值传递给它的方法。
我认为使用 5 个参数是可以的,因为一些 Objective-c 默认方法也有 4 个参数,例如
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(updateConvMenu:)
notificationName:@"NSConvertersChanged"
object:converterArray];
我们可以做的更清楚的是为您的代码提供更好的格式
免责声明:我知道关于目标 c 的 zilch
没有看到有问题的代码就很难说,这完全取决于你在做什么。说一个有五个参数的方法是不好的做法,这有点假设,尽管保持方法参数的数量尽可能少当然是好的做法。
这个方法听起来像一个内部“帮助”方法(而不是 API 的公开暴露组件)这一事实为您提供了比其他方式更多的回旋余地,但通常您不希望处于一个方法的情况正在根据一些神秘的参数组合做不同的事情。
当我遇到具有令人不安的长签名的方法时,如果不创建冗余代码就无法对其进行重组,我通常会执行以下操作之一:
用几个更简洁的方法来包装进攻方法。例如,您可以为每个“实现”创建一个方法,并用一个好名称指示其目的,只接受该目的所需的参数。然后它将委托给内部的、更臭的方法。臭方法只会在您的“特定于实现”包装器中使用,而不是分散在您的代码中。使用命名良好的包装器,开发人员将了解您的意图,而无需破译参数的含义。
创建一个封装方法所需数据的类。如果该方法的作用取决于某个系统或子系统的状态,则封装该状态!我经常用“XXContext”类型的类来做这件事。现在,您的方法可以检查和分析这些上下文数据并采取适当的措施。这也有利于重构。如果将来该方法需要更多信息来完成其任务或实现新功能,您可以将此数据添加到参数对象,而不必更改使用该方法的每一位代码。只有需要使用更改的代码才必须为上下文数据提供适当的值。
这是那些很难明确回答的主观问题之一。
我不介意 Objective C 方法中的许多参数,因为它可以使被调用的 API 更加清晰(并且参数也可以很好并且类型安全)。
如果您可以将这些许多函数提炼成数量较少的函数(或从所有其他函数调用的“基本”函数),那么这可能也会使代码更简洁,更易于理解和阅读。另外,如果您对该“基本”功能进行更新,则功能更改将通过您调用操作的所有方式来获取(当然,这也可能是好事或坏事)。