做一件事 - 这条规则要走多远？

Question

所以在"清洁代码"一书中有"做一件事"的规则.但是我们真的需要走得多远.

例如以下语句:

Settings.Default.BaudRate = baudRate;
Settings.Default.COMPort = port;
Settings.Default.DataBits = dataBits;
Settings.Default.Handshake = handshake;
Settings.Default.Parity = parity;
Settings.Default.ReadTimeout = readTimeout;
Settings.Default.WriteTimeout = writeTimeout;
Settings.Default.CommunicationTimeout = communicationTimeout;
Settings.Default.Save(); 

好的,确定这里有不止一个声明,但它确实让我觉得他们只是做了一件事.保存设置.

我有一个功能.你真的会采用这个appart并为每个设置设置一个方法吗？

你什么时候坚持这个规则什么时候不遵守？

Answer 1

本书的下一部分,每个功能的一级抽象,对回答这个问题大有帮助.所有这些语句都处于相同的抽象级别,因此这个函数已经做了一件事,保存了设置.

Answer 2

看起来对我来说完全有效.该代码的明显方法名称是SaveSettings,表明该方法完全有一件事.没什么好担心的.

Answer 3

我将它们全部保存在一个SaveSettings()函数中 - 如果你将它们各自放在它们自己的函数中,你仍然需要从另一个函数调用所有这些函数.

Answer 4

是的,每种方法都应该只做一件事.但那是什么一件事？

这取决于您的方法所处的抽象级别.保存单个设置的方法(属性)是一个相当低的抽象.然后,下一个更高的抽象将是所提出的SaveSettings方法.

在顶部你有一个方法/功能main,它只做一件事:整个程序......

Answer 5

我没有读过那本特定的书，但至于概念......

“一件事”并不意味着“一行代码”。“一件事”意味着函数中的一切都应该在逻辑上相关。

我会质疑之前的一些海报，说“saveSettings”是“一回事”。也许这只是措辞上的粗心，但我会借此机会指出潜在的陷阱。在您的情况下，它更像是“saveCommunicationSettings”，我认为它很容易符合“一件事”的定义。如果您将“Settings.Default.customerLoyaltyDiscount= ...”添加到该列表中，我会说您可能处于危险境地，因为您现在将通信设置与定价计算设置混合在一起。

在现实生活中，决定什么是合理的凝聚力不是一个公式，而是一个需要运用智慧的判断力。计算订单总额的函数是否应该包括销售税计算？可以说这是两件事：订单上所有商品的总价和计算销售税。但您也可以争辩说这只是一个：找到订单的总价，无论涉及到什么。在实践中，我经常根据逻辑的复杂性做出决定。如果计算订单总额所需的只是一个简单的循环，将所有商品的价格相加，然后从表格中获取销售税率并相乘，那么我可能会在一个函数中完成所有操作。如果还有更多 - 就像我这些天正在研究的系统一样，