> The problem with including the name of a pattern in the name of a class is that this permits you the feeling of having created a useful name without actually having done so. Pattern names don't generally reflect concepts in your application<p>I thoroughly disagree. In my experience, the domain of the app doesn't really matter when you're trying to make sense of the architecture of a software to fix that bug you were commissioned for, especially when you had never heard of that software two days ago and you'll never hear of it again in two days.<p>On the other hand, having a way to very quickly know which class does what in a software sense (through the patterns in the name) allows to make a rough diagram of the software in 5/10 minutes just by looking at the class list which is to me crucial to get an understanding of whatever mess is happening in there
> I mean, if I see a class named ReportVisitor, I immediately know what the author’s intent was, and what the structure of the code is.<p><a href="https://blog.cleancoder.com/uncle-bob/2015/07/05/PatternPushers.html" rel="nofollow">https://blog.cleancoder.com/uncle-bob/2015/07/05/PatternPush...</a>
I generally agree with the rule and the reasoning given for it. But I think the worry about the "Fake" suffix here is missing a crucial point.<p>This is test code. In test code, the "business" at hand is exercising the production code. To put it another way, test code doesn't have the same business domain as the application code.<p>Therefore, in test code "Fake" <i>is</i> a domain-specific term, and it is perfectly appropriate as part of a class name.
This classic rant by Steve Yegge gets shared almost every time object oriented design pattern debates come up on HN, but I'll share it again since new members join regularly: <a href="http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html" rel="nofollow">http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...</a><p>You may or may not agree with it, but it does frame the debate in an interesting way.
I think naming should reflect whether a class encodes business logic or is ‘glue’ to make that work.<p>Nowadays, many people use languages with huge libraries. Consequently, most logic is business logic. There, name classes (and functions, and argument names) after their business use, not after their implementation.<p>However, parts that aren’t business logic such as wrappers of external libraries or generic containers you have to implement because they aren’t available in the language’s ecosystem should use generic names, and can use pattern names, because those tell callers what they do.<p>As a made up (and not <i>that</i> good) example, one would have<p><pre><code> def pow(a,b)
</code></pre>
but<p><pre><code> def valueAfterNYears(initialValue, interestPerYear)
</code></pre>
(Yes, these aren’t functionally equal. That’s part of why I said it wasn’t that good of an example)
This blog reminds me of one of the most frustrating naming patterns I see among coworkers, former students I TA'd, and open-source code: reversing the adjective or adverb with the noun. I attribute it to language barriers but seeing, in this blog, "VerseFake" instead of "FakeVerse" peeves me.<p>Its a VERSE class, not a FAKE class. It just so happens the class is described as a "fake" so...FakeVerse. Its like saying "Hey look a person tall!". While it sounds silly in english its incredibly pervasive in programming.<p>Another common pattern that drives me nuts is when people prefer nouns over strong verbs in functions. doDatabaseRestore instead of restoreDatabase.
> Good Morning/Afternoon/Evening as the case may be.<p>This is very inefficient. Try this instead:<p>> Good day.<p>Although once you do that, you start to recognize that the entire construction might be unnecessary in this context.