Shameless blog plug, but it does count as a rant 😅

Seriously folks, stop calling everything a service.

https://likelikeatemyshield.com/pos...

I like it.

Good stuff

Yeah 'service' kinda feels meaningless... just takes up space.

Nice.

You did a great service writing this.

Thank you! I ended up reading yours and 2 of Kevlin's articles.

I wish interviews explicitly asked candidates to name/rename a few classes and methods/functions.

Great article. Though I would argue most part of the article for .Net development.

You can't just name a class "Calculator" because it calculates saying that's common sense but no I disagree. That can make sense as the name of a solution, project, or namespace but not as the name of a class per se.

.Net community tries to make everything as less generic as possible because it has a team based lifecycle.

Calling a class a service means it could be made use of globally and even externally when exposed. If a .net developer appends "Service" to the end of a class name and have it for a specific Model/Controller, then "they" specifically are doing things wrongly.

A Calculator can have:
Model -> View-Model -> View -> Controller

And can also have a "Repository" in-between the model and controller to make things less tightly coupled when working on larger projects.

CalculatorModel
CalculatorView
CalculatorViewModel
CalculatorController
CalculatorRepository

The suffixes aren't there because it needs to sound programmer(y) like stated, it's there to give a context on what the classes are for without the need of opening the class for review or requiring extra context to know what it does.

If the developer eventually creates a "CalculatorService" class then it would be assumed that it's a class with helper functions for calculation but in real case, services have well-defined names like "ForexCalculatorService", "PaypalPaymentService", "FacebookScraperService".

Having "service" in front of a name simply let's other developers know that the class can be used to access certain features based on its name, available globally and not specific to a view/model since we already have controllers with helper methods for that.

@GiddyNaya I agree with you on the Model View Controller part. Thats just another example of an architectural pattern which I mentioned in the post.

I wasn’t suggesting that you should simply call something ‘Calculator’. Thats not very descriptive. But CalculatorService is even worse.

I disagree with your examples in your last reply. FacebookScraperService could simply be called FacebookScraper. The Service suffix adds no extra information and only serves to make the name longer. FacebookScraper already tells me what the class does. It scrapes Facebook for content.

@LLAMS FacebookScraper can also have a view, model, controller, repository, can as well be seen as a whole project... So in .net we'd ask FacebookScraper what?

@GiddyNaya But if you saw a CLASS called FacebookScraper, would you still be confused about what it did?

I’m not talking about whole projects here. I’m talking about classes.

To be honest if I saw a class called FacebookScraperModel I’d wonder what it was for. But then I’m not a big believer in MVC as an effective architectural pattern for a whole application.

@LLAMS You can choose not to agree with my purview and that's fine. It's not a winning game.

If also you ponder about the use of a class with "Model" appended to it's name when seen at first glance then there is no need for all the arguments.

@LLAMS I would even argue with Kevlin's fightback on "Exception" at the end of class names. His points are vague and makes no real sense to me.

Wait until you start naming your 1 thousandth class and you'll know class names are really limited.

When I see a class with "Exception" at the end of its name immediately I know that is a class that handles an exception and also extends from an exception... That's the signature of most languages not even a developer generated pattern.