What does really mean Single Responsibility-CodePudding

I am learning SOLID principles. I read a lot of things about the single responsibility principle but I don't get it exactly. I will give an example that what do I want to say.

Let's say we have an article service for managing articles. How should I design article service by single responsibility.

Is like that:

class ArticleService{

  create(){};  
  read(){};
  update(){};
  delete(){};

}

Or create a class for each operations like that :

class ArticleCreateService{

  create(){};

}

class ArticleReadService{

  read(){};

}

// and so on ...

According to single responsibility which is the best way to managing articles?

Thanks.

CodePudding user response：

As Robert C. Martin (Uncle Bob) says about Single Responsibility Principle:

There should never be more than one reason for a class to change

So your first option is better to comply with Single Responsibility principle:

class ArticleService {
    create(){};  
    read(){};
    update(){};
    delete(){};
}

As when you will want to edit ArticleService, then there is just one reason to edit this class. And this reason is to edit Article.

The second version looks like Interface Segregation principle. However, it should be slightly modified.

class ArticleCreateService
{
    void Create() { }
}

class ArticleReadService
{
    void Read() { }
}

At first, we need to segregate methods of class. We can segregate by Create() and Read() methods. So let's create these interfaces:

public interface IReadable
{
    void Read();
}

public interface ICreatable
{
    void Create();
}

And modified version of ArticleService could look like this:

public class ArticleService : IReadable, ICreatable
// public class ArticleService implements IReadable, ICreatable // in TypeScript
{
    public void Read()
    {
        throw new NotImplementedException();
    }

    void ICreatable.Create()
    {
        throw new NotImplementedException();
    }
}

CodePudding user response：

The S in solid stands for that a class or method should only have one reason to change. That means that a class, module or method should have a single well defined responsibility.

In this particular case you might want to (for whatever reason) extend read, or write etc to read and write from/to different sources for example. Therefore keeping those responsibilities in a class each, will make it easier to extend i.e:

read class -> only reads data -> this class can then be extended with more methods like readFromExcel or readFromDB. Reading is a single responsibility. In that class each method can have separate niches of that one responsibility i.e readFromExcel only has one responsibility i.e readingFromExcel only.

class Read {
readFromExcel();
readFromDB();

}

A good rule of thumb is: does my class have one single responsibility? and what is that responsibility? Can my method and classes be extended without them losing that one single responsibility? In the above example class read has (S)ingle responsibility of only reads data and within it method readFromDB(); only reads files from the database.