Если вы увлеченный разработчик, который заинтересован в том, чтобы научиться писать высококачественные программные решения, то вы пришли по адресу, мой друг.
Одним из наиболее распространенных и эффективных принципов разработки программного обеспечения являются принципы SOLID, введенные Робертом К. Мартином, известным как дядя Боб. Они предназначены для того, чтобы сделать дизайн программного обеспечения более понятным, гибким и удобным в обслуживании.
SOLID – это аббревиатура от 5 принципов проектирования:
- S единая ответственность.
- O ручка закрыта.
- L замена Лискова.
- I разделение интерфейса.
- D инверсия зависимостей.
В этой статье мы поговорим о первом и самом простом из них – принципе Единой ответственности .
Принцип единой ответственности гласит:
” У класса должна быть только одна причина для изменения”
Но что означает фраза “только одна причина” !
Вы знаете, я считаю, что примеры – лучший учитель. Давайте прочитаем следующий фрагмент кода, чтобы понять.
class MusicPlayer{
void playMusic(){
System.out.println("Let the fun begins!");
}
void openPhoto(){
System.out.println("Really! should I open the photo now?");
}
}
Как вы можете видеть, у нас есть класс музыкального проигрывателя, который может воспроизводить музыку и открывать фотографии.
Попробуйте представить, что этот класс существует в каком-то проекте компании XYZ, в которой вы работаете. Халед – фотограф в XYZ и использует функцию open photo для открытия фотографий. Али – еще один сотрудник, который увлекается музыкой и использует функцию воспроизведения музыки.
Если Халед решит изменить способ открытия фотографий, вы откроете класс музыкального проигрывателя и измените функцию openPhoto. Точно так же, если Все, то так решил совершенно другой сотрудник и, возможно, из другого отдела. Вы сделаете то же самое, но с функцией PlayMusic.
У нас в классе есть две разные причины для изменения, и они не связаны друг с другом. Один для музыки, а другой для фотографий. Кроме того, какова связь между классом MusicPlayer и функцией open Photo! Я знаю, вы думали, что openPhoto не должно быть там.
Класс выглядит как студент, который работает на двух совершенно разных работах. В разработке программного обеспечения это плохая практика. Чем больше класс может что-то делать, тем больше он подвержен изменениям, следовательно, больше ошибок и проблем.
Мало того, попробуйте представить, если бы мы решили удалить несколько строк кода из play Music, чтобы обнаружить, что openPhoto выходит из строя. Разные вещи в одном месте могут влиять друг на друга. Жуки повсюду, мой друг, жуки повсюду!
Итак, давайте разделим обязанности и дадим классу одну причину измениться.
class MusicPlayer{
void playMusic(){
System.out.println("Let the fun begins!");
}
}
class PhotoViewer{
void openPhoto(){
System.out.println("What about now should I open it?");
}
}
Теперь, если мы решим изменить функциональность фотографий в любое время, мы не будем трогать функциональность музыки, и наоборот. Кроме того, функции, как известно, логически связаны с именами их классов.
На практике очень сложно дать классу только одну причину для изменения, поскольку существует множество функций, но что вы можете сделать, так это максимально связать его функции. Это обычно известно как сплоченность в разработке программного обеспечения. Классы с высокой когезией являются показателем хорошего дизайна.
Вы можете применить принцип единой ответственности и к функциям. Функция должна выполнять одну конкретную задачу, не больше и не меньше.
Всегда спрашивайте себя, когда вы пишете функцию, что она делает? если вы говорите, что это делает что-то “и” что-то. И здесь означает, что вы делаете это неправильно.
На данный момент это конец нашего путешествия.
Скоро мы отправимся в другое путешествие по принципу “открыто-закрыто”. Просто ждите этого!
Оригинал: “https://dev.to/amrsaeedhosny/single-responsibility-principle-3ajo”