Like I said before, I started to buying physical programming books this year (2017).
About a month ago, I started to look for the next book to buy. I was considering books on TDD, OOP, or Architecture; and something that can help me do unit testing because I’m planning to introduce it to the current project I am working on.
The book title “Growing Object Oriented Software Guided by Tests” sounded very good. So I started googling for reviews for that book.
One of the reviews that I found was Steve Smith’s. I was a .NET developer so his name is familiar to me (I think his name is famous in the .NET world).
One thing from the review that made me interested about the book is this quote:
“We value code that is easy to maintain over code that is easy to write.”
Another thing is the part where Steve Smith disagrees with the authors of the book:
I made one note where I have to disagree with the authors. On page 297 they note their preference “not to name classes or interfaces after patterns” using terms like “Repository.” Their argument is that “the clients of [a class] do not care what patterns it uses.” Here I respectfully disagree, since frequently the use of a pattern name in the name of a class makes its intent and how one expects to use it much more clear.
I was very interested because during the time I was reading Steve Smith’s review, I was having a task where, I think, the resulting structure of my code looks like it follows the template and strategy patterns; but the classes that I created do not follow the standard naming of template and strategy patterns. I’m not even sure if there are standard names for the classes and interfaces involved in these patterns. (Maybe they don’t have standard names??)
All that was in my mind is that as long as I am able to make the dependencies of the modules manageable, while following what I understood about OOP principles, everything will be okay.*
… so that made interested to know what the reasoning is behind the advise of not naming classes based on the standard names of the design patterns.
My initial thoughts about the reasoning behind the advise of the authors is that, maybe, they were thinking about the requirements constantly changing problem: when the requirements change, the implementation might change, and our code might change so that the pattern that we previously used is not the same as the pattern we are using in the new implementation. And if we previously named our classes based on the known patterns, and now we change it to use a different pattern, the ones that will be reading our code in the future might get confused. “Why is this class named like this pattern when it is using another pattern?”
Well, I’m not sure. I already have the book. It arrived about a week ago. So I have to finish the book to confirm those thoughts. 
* I got this idea of not being very much obsessed with design patterns from “Don’t Get Obsessed With Design Patterns” by Joel Rodriguez…
I believe that knowing object-oriented design principles and applying best practices like SOLID, KISS and YAGNI are far more important than design patterns themselves. If you apply these principles, patterns will come out naturally.
… and from “What Are Software Design Patterns Hiding From You?” by Muhammad Umair.
I ask for you to not try too hard with the documented software design patterns (especially when you are starting). We use patterns all the time in our daily lives, and you should focus on these first.
