Блог

Я читал о принципах проектирования SOLID, в настоящее время рассматриваю «Принцип единой ответственности», но мне было любопытно, как использовать этот принцип. В компании, в которой я работаю, у нас есть DAO, у которых есть методы read , insert amp; update для управления записью в базе данных.

Может ли что-то подобное нарушить «Принцип единой ответственности»? Если да, нужны ли вам классы для каждой вставки, чтения и обновления?

Пример DAO:

 class UserDAO {
    public function read(where: object) {
        // read code
    }

    public function insert(user: User) {
        // insert code
    }

    public function update(user: User) {
        // update code
    }
}
  

Принцип единой ответственности гласит, что

У класса должна быть только одна причина для изменения.

Допустим, у нас есть UserDao с методами чтения, сохранения, удаления, обновления. Таким образом, этот класс будет изменен только тогда, когда произойдут изменения, связанные с пользователем. Таким образом, у него есть единственная причина для изменения, то есть Пользователь.

Итак, я думаю, что это не нарушает SRP (принцип единой ответственности), если реализовано правильно.

 void save(User user){
//user related logic
}

void save(User user){
// user related logic and address logic encapsulated inside address class
//eg: address.getAddress(user.getId);
}
  

В приведенном выше случае это не нарушает SRP, поскольку метод сохранения будет изменен только при изменении пользовательской логики. Логика адреса обрабатывается классом адреса как таковым.

Например: если метод сохранения выглядит так:

 void save(User user){
Address address = new Address();
 //Address logic
 Payment payment = new Payment();
 //Payment logic
}
  

В приведенном выше коде любые изменения в адресной или платежной логике также изменят этот метод сохранения DAO. Это нарушает SRP.

Итак, это действительно зависит от реализации.