Question

We know there are services in windows but I am reading a book by Ed Snider and he uses the term “service” whenever his program requires a certain feature/functionality.

Like he creates a navigation service which allows page to navigate to another page. The service is essentially an interface in C# which is then implemented.

My question is, is this common to call an interface a service? I thought a service had more specific meaning?

It does makes sense that an interface encapsulates something, some functionality and to call it a service but I am too used to service as in a window service and as such expecting a service to be an application, not just an abstract class or interface!?

In cloud terminology as well, we see software-as-a-service which means a service is an application.

So is the term “service” justified to be used for essentially for an abstract class or interface?

Was it helpful?

Solution

My question is, is this common to call an interface a service?

No, but it's common to refer to IFoo as "the Foo", since the interface tends to represent the real thing, and constantly adding "the interface of ..." usually doesn't really add clarity to an explanation.

Similarly, if someone was referring to IFooService as "the Foo service", they were just using shorthand for what is technically "the interface of the Foo service".

he uses the term “service” whenever his program requires a certain feature/functionality

"Service" is a very common word in the field of software development, because it describes something that is used as the bread and butter of software architecture: a service serves its consumers.

This mean that a "service", without further context, is very ambiguously defined. You've already noted a few, e.g. Windows services being hosted background progresses, or SAAS using "service" to mean "network-distributed application". Two very different things.

he uses the term “service” whenever his program requires a certain feature/functionality

When looking at clean architecture from a bird's eye view, almost any well-defined SOLID-respecting class that is not a data class can be described as a service. It serves their consumer with the necessary information, and therefore the workings of this class are a "service".

Generally speaking, if a certain feature is big enough to be considered a single responsibility on its own, then it can be housed in a class of its own and that class then can be described by default as the "[feature] service" (e.g. navigation service).

When there is a more appropriate name, we tend to avoid "service". E.g. repositories, factories, controllers, ... In these cases, a more distinct name that is more descriptive of the class' responsibility is available, and therefore favored.

But there are many classes whose responsibility is less strictly defined, which means that they usually get called a "service" for lack of a better name.

Note that you can argue that "service" is about as bad of a name as "manager" (a commonly touted bad naming example), and while I agree with that good practice suggestion in principle; if no better name is available, it's going to be the best name you've got.

Licensed under: CC-BY-SA with attribution
scroll top