
Don't Name Classes After Patterns. Mostly - allending
https://sender.cloudy.email/campaigns/paxjhchaiasjoifsiw/webversion/jdnapfbdgjegdqmdeduwc
======
jcelerier
> 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

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.

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

------
jackblemming
> 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.

[https://blog.cleancoder.com/uncle-
bob/2015/07/05/PatternPush...](https://blog.cleancoder.com/uncle-
bob/2015/07/05/PatternPushers.html)

------
wool_gather
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.

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.

Therefore, in test code "Fake" _is_ a domain-specific term, and it is
perfectly appropriate as part of a class name.

------
hliyan
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: [http://steve-yegge.blogspot.com/2006/03/execution-in-
kingdom...](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-
nouns.html)

You may or may not agree with it, but it does frame the debate in an
interesting way.

------
Someone
I think naming should reflect whether a class encodes business logic or is
‘glue’ to make that work.

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.

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.

As a made up (and not _that_ good) example, one would have

    
    
       def pow(a,b)
    

but

    
    
       def valueAfterNYears(initialValue, interestPerYear)
    

(Yes, these aren’t functionally equal. That’s part of why I said it wasn’t
that good of an example)

------
jzoch
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.

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.

Another common pattern that drives me nuts is when people prefer nouns over
strong verbs in functions. doDatabaseRestore instead of restoreDatabase.

~~~
ofrzeta
It just makes sense, because you have the "parent class" in front and can
order classes in docs etc. "AnimalLand", "AnimalWater", "AnimalAir" instead of
"LandAnimal", "WaterAnimal" and "AirAnimal".

In fact I would probably prefer databaseRestore to restoreDatabase for the
same reason because it would allow to cognitively group database methods in
your flat namespace instead of grouping restore methods.

~~~
segfaultbuserr
> _In fact I would probably prefer databaseRestore to restoreDatabase for the
> same reason because it would allow to cognitively group database methods in
> your flat namespace instead of grouping restore methods._

This is especially important in pure C. If OOP-style programming is adopted,
databaseRestore() can be strictly interpreted as a method of the Database
class without ambiguity, and its first parameter is the object the operation
is applied onto. In a sense, even old C & POSIX functions such as fopen(),
fclose(), fseek() can be seen as a rudimentary form of OOP. On the other hand,
restoreDatabase() may perform other operations that change the state outside
of the database object.

~~~
heavenlyblue
> restoreDatabase

It may do anything because it was probably written by an intern

------
antonvs
> Good Morning/Afternoon/Evening as the case may be.

This is very inefficient. Try this instead:

> Good day.

Although once you do that, you start to recognize that the entire construction
might be unnecessary in this context.

------
hydroxonium
First three lines of the article were so unnecessarily wordy.

For an article that is supposed to be about effective communication.

