I cannot understand the principle of the sole responsibility (Single Responsibility Principle)



  • In theory, everything is understandable, and in practice it is always difficult. They are linked to the fact that it is not understandable on what scale this "the only duty" should be considered. I need to work with the database. If I create a class DataBaseInteracting You think he'll have one duty? But that's when he tapes the data into the database and reads them and updates them. Maybe it's better to create three classes: DataBaseWriterDataBaseReader and DataBaseUpdater?



  • The principle of a single duty is practically applicable to any scale: method, class, module, subsystem, etc. In choosing a duty, as always, there must be some reasonableness. Moreover, all principles can sometimes be derogated from. It'll come with experience.

    In your example, I'd say it's necessary to break the class. DataBaseInteracting No action. The duty of data storage is quite atomarine, on my look, and it is not necessary to be read/recorded/renewed. It makes sense, however, to share in other planes. For example, if there is a SQL code in this class, it should be delivered in a separate class. Moreover, if there is a need for several OBD support, there should be several of these classes.

    If there's a need for some high-level change in data storage, you'll change the class. DataBaseInteracting♪ If there's a bang with a non-optimal request, you'll change the class that's making requests and you won't even touch. DataBaseInteracting♪ If you need to support the new OBD, you'll just add a new class. You know?

    All these classes should be in the DAL project. And this project should be based only on what relates to the logic of interaction with the vault (OBD in your case). So you'll support the SRP at the project level.




Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2