仅在良好的代码可读性方面（但可能为方法调用支付一些性能），是否有一个好的做法将复杂方法的部分功能拆分为几个较小的方法？或者这是某种“坏风格”？
问问题
160 次
4 回答
4
最基本的规则是你的方法应该只做一件事。如果您检测到它正在做许多不同的事情，那么您就有了明显的重构机会。
如果您的方法具有单一的责任，但无论如何大小太长，请尝试将“帮助”功能提取到分离的方法中。您甚至可以检测到可以提升为单独类的代码。
TDD 开发是避免此类问题的一种很好的方法，因为它确实有助于清楚地分离关注点并避免仅仅为了可测试性而在单个方法上编写一堆代码。如果您不编写简洁的方法，则很难正确地测试它们。
于 2012-05-23T13:35:35.343 回答
3
如果你考虑重用代码（DRY原则），你应该考虑重构。根据功能将方法内容拆分为不同的小模块，使其可重用。例如：如果您有一种方法可以保存客户注册详细信息并为他创建新订单。您可能可以检查很多方法，例如CheckUserExist,SaveUser和SaveOrder. 您应该能够根据需要在代码的其他区域重用此功能。将其拆分为模块化的部分也使您的代码更具可读性。
于 2012-05-23T13:38:07.117 回答
3
Unclebob (Robert C. Martin) 认为方法不应超过 4-5 行代码。关于这一点，他的座右铭是“萃取至滴落”。就个人而言，我认为这是一个非常好的做法。
Visual Studio 允许您通过按 CTRL+R、M 来提取方法。
于 2012-05-23T13:38:45.937 回答
1
除了克劳迪奥的回答之外，如果检测到一些气味，则意味着您必须重构和拆分代码。
1- 非DRY代码：如果您发现自己将某些行复制/粘贴到多个位置，这是一种难闻的气味，需要放置在中心位置，并尽可能多地调用。
2- 数百行的方法：任何好的方法都不应超过 50 行代码，可能多于或少于这个数字，但请放心，这种 346 行的方法不是一件好事。
3- 参数太多：方法中的一长串参数会使可读性和代码质量变差。
4-代码入侵：使用许多从另一个类阻止的方法，应该存在于这个类中。
希望有帮助。
于 2012-05-23T13:39:32.893 回答