我目前正致力于单一任务,我知道设计对于标记标准至关重要。
目标是基本上读取文本文件并返回每个单词出现的计数。有一些小的要求,包括实现二进制树(类字,其中包含单词的字符串及其出现的计数),并具有文本文件中单词总数的计数。
当我填充树时,我可以记录我读过的单词数。我的方法fillTree可以返回文件中的单词数,而不必再次迭代它,但显然方法名称根本不与它相关,我们已经被教导方法应该只做一件事。将这两个过程分开或保持原样是否更好?或者我是否需要完全重新考虑我的整个方法?
请耐心等待,因为这是我在这里的第一个问题。谢谢!
答案 0 :(得分:2)
优雅与表现之间往往存在紧张关系。
假设您有一个函数std::map<std::string, size_t> computeStatistics(std::istream& input)
,它解析输入流并计算每个单词的出现次数,并将它们存储到map
。
然后你可以实现:
size_t countOccurrencesOfWord(std::string const& word, std::istream& input)
,解析然后查看地图。size_t countWords(std::istream& input)
,解析然后总结计数。每种方法都有一个责任,但是有很多重复的工作。我建议改为暴露中间步骤:
class FileStatistics;
FileStatistics computeStatistics(std::istream& input);
这个类可以公开简单的方法:
size_t FileStatistics::getOccurrencesOfWord(std::string const& word) const;
size_t FileStatistics::getTotalNumberOfWords() const;
在内部,您可以选择其结构。我的推荐结果为std::map<std::string, size_t>
,总数为size_t
。
答案 1 :(得分:0)
从长远来看,命名两个单独的方法可以更好地进行代码维护。如果将来有人必须在您缺席的情况下携带此项目,唯一的名称和功能将帮助他更轻松地理解和调试。这就是为什么建议只有一种方法只做一件事,方法名称应该能让开发人员知道它实际上做了什么。
答案 2 :(得分:0)
我们被告知一种方法应该只做一件事
差不多。不幸的是,程序比这更复杂。如果你把这个想法发挥到极致,那么方法将没有参数;)因此,在编写接口和编写程序时,需要考虑方便性和可用性。这需要考虑,但是您获得的体验越多越容易,您对解决问题的理解程度越高,以及任何客户端将如何使用该界面。
在这种情况下,单词计数和单独的单词计数确实是不同的。考虑一下:如何将其参数化为一种方法?你用什么特殊的奇数限定词来表示“所有单词”? NULL
或空字符串将是C接口中的常见选择,甚至在某些C ++接口中也是如此。但是,我不认为这是一个设计良好的界面(有些人不同意)。
IMO,理想的界面将有两种不同的方法:
size_t wordCount() const;
size_t countOccurrencesOfWord(const std::string& pWord) const;
我之前不鼓励的界面是:
// eah, just pass NULL or an empty string for the word count of the text file
size_t countOccurrencesOfWord(const std::string* const pWord) const;
然而,另一个考虑因素是公共界面和私人界面。您的公共接口可能提供2种方法,但如果内部实现在某些情况下可能选择相同的底层实现,或者在问题类似时稍有变化。假设您的类包含了一个C接口,该接口具有允许size_t SomeTypeCountOccurrencesOfWord(SomeTypePtr pSomeType, const char* const pWord);
参数NULL
的{{1}} - 那么两个单独的方法仍然是一个不错的选择,即使它们的底层实现几乎完全相同。
我最初采用的方法是首先填充树,然后提供必要的接口来计算单词或所有单词。然后,如果我确定缓存值是个好主意,我可以在事后轻松引入变量。
答案 3 :(得分:0)
我建议你想问一下fillTree
的回报值应该是多少。很可能是成功代码。
您是否需要跟踪元素数量?如果是这样,我会想到将数据直接存储在数据结构中就可以了。
话虽如此,如果它使代码更简单易读,fillTreeAndReturnElementsStored
肯定不是一种不合理的方法。
答案 4 :(得分:0)
坚持单一责任原则(一个班级或方法应该只做一件事,一件事)。使用其他人建议的两种方法将是更好的设计。
许多软件项目的主要问题之一是它们不仅违反了单一责任原则,而且最终违反了open-closed principle。