关于方法实现的几点思考

在罗伯特·C·马丁（Robert C. Martin）的“清洁代码”的第17章中，作者描述了“ 代码气味 ”的概念，即在开发中的实践，尽管它们没有明确地违反任何标准（无论是否为未成文的），但它们却留下了缺乏经验或缺乏纪律的“恶臭”。 我喜欢这个主意； 在我看来，我经常遇到这些“代码异味”（鉴于我经常与不同的团队合作），它们会使代码难以破译和维护。

以方法的参数数量为例。 根据Martin的说法，最佳情况下将有零个参数，但是任何数字（最多三个）都是可以接受的。 当然，三是作者选择的任意数字，但我认为我自己的限制将落在同一范围内，尽管有时肯定取决于条件。 有时，不可能对参数列表大小施加这样的限制，尤其是在处理已经建立的代码库时，但是我确实有一些建议。

1. 是否有大量参数源自同一对象实例？ 尝试改为传入包含对象，并根据需要在方法内部引用属性。
2. 或者，可以在对象本身上实现该方法，从而无需在该方法内引用另一个对象。
3. 有时，如果不对所涉及的代码进行重大重构，就不可能更改参数列表。 如果重构的风险过高（通常是由于时间限制），一种选择是建立一个瞬态对象，该对象封装完成方法功能所需的所有属性，然后将单个对象传递给方法，或再次，使该方法存在于瞬时对象本身上。

另一种“臭”的做法是“输出争论”的想法。 期望参数应该仅仅是方法的输入，而不能被方法的逻辑所改变。 建议这种做法是在OOP之前的日子进行保留，在这种情况下将需要输出参数，但现在不再如此。 现在，更好的做法是将保留字“ this”视为输出参数。 同样，表达这种做法的最好方法是让受逻辑影响的对象自己实现该方法。

标志参数是传递给方法的布尔值，表示该行为可能正在执行两个单独的功能。 更好的替代方法是将逻辑实现为两种方法，一种是将参数设置为true时执行的逻辑，另一种是将参数设置为false时执行的逻辑。 这迫使您也为这两种实现提供了更有意义的函数名称，从而使每个使用它们的人都更加清楚每个函数的意图。 有时以这种方式使用标志参数，因为两条逻辑路径在彼此分开之前共享大量逻辑步骤。 如果是这种情况，最好创建第三个方法来实现公共逻辑路径，同时在其他两个方法中保持发散逻辑。

作者没有提到但与该主题相关的一个想法是，使用局部方法变量作为方法的返回值，而不是返回对象本身。 为了澄清起见，请参见下面的两个实现示例。 如果满足条件，第一个将简单地返回数字，而第二个将数字设置为局部变量，并在方法末尾返回该变量。

int getNumber(){
		if(condition1){
			return 1;
		} else if(condition2){
			return 2;
		} else {
			return null;
		}
	}

int getNumber(){
		int returnValue = null;
		if(condition1){
			returnValue = 1;
		else if(condition2){
			returnValue = 2;
		}
		return returnValue;
	}

我觉得第二种实现是有优势的，至少有一个原因。 该方法从哪里退出总是很清楚，因为它只能在一个地方退出。 这使得它更容易理解和维护。

最后，简单地说就是“死函数”，即系统中任何地方都没有调用的函数。 源代码控制的存在是有原因的； 用它！

参考： Keyhole Software博客上的JCG合作伙伴 Robert Rice对方法实现的一些思考 。

翻译自: https://www.javacodegeeks.com/2013/10/a-few-thoughts-about-method-implementation.html