SOLID частина 1
Пропоную поговорити про принципи солід. Цей концепт був вперше представлений у 2000 році Робертом Мартіном, і він все ще не втрачає своєї актуальності. Тут ми не будемо сперечатися, чи потрібен він нам чи ні, бо SOLID дійсно може бути оверкілом для нескладних проектів. Тим не менш, маючи в голові ці принципи, легше писати гарний код. У цій серії дописів розберемо окремо кожен принцип і подивимося на нескладні приклади його застосування.
Перший принцип - SRP (single responsibility principle). За цим принципом, в класа (функціїї, модуля і тп) повинна бути тільки одна зона відповідальності і одна причина для змін.
Розглянемо приклад:
В коді можемо подивитися невеликий приклад SRP в дії. Ми маємо бізнес задачу - реєструвати юзера і відправлять йому імейли. Початково під час розробки є бажання інкапсулювати цю фічу просто в один клас (функцію). Тобто юзер би і дані юзера записував і імейли відправляв. Але це порушує SRP. По перше, в User більше однієї зони відповідальності (і юзер і імейли). По-друге, в нього більше однієї причини для зміні - щось змінилося в логіці реєстрування юзера або змінилися реквайременти для емейлів. Розділяючи це на два класи, ми дотримуємося SRP. Можна ще створити RegistrationService який би керував процесом реєстрації за допомогою цих двох класів.
Антипатерном принципу Single Responsibility є God Object. Це коли один клас (об’єкт) знає про всю логіку великої фічі/додатку.
Пропоную поговорити про принципи солід. Цей концепт був вперше представлений у 2000 році Робертом Мартіном, і він все ще не втрачає своєї актуальності. Тут ми не будемо сперечатися, чи потрібен він нам чи ні, бо SOLID дійсно може бути оверкілом для нескладних проектів. Тим не менш, маючи в голові ці принципи, легше писати гарний код. У цій серії дописів розберемо окремо кожен принцип і подивимося на нескладні приклади його застосування.
Перший принцип - SRP (single responsibility principle). За цим принципом, в класа (функціїї, модуля і тп) повинна бути тільки одна зона відповідальності і одна причина для змін.
Розглянемо приклад:
class User {
constructor(name, email) {
this.name = name;
this.email = email;
}
getUserInfo() {
return `Name: ${this.name}, Email: ${this.email}`;
}
}
class NotificationService {
static sendEmail(email, message) {
console.log(`Sending email to ${email} with message: "${message}"`);
}
}
const user = new User('Alice', '[email protected]');
console.log(user.getUserInfo());
NotificationService.sendEmail(user.email, 'Welcome to our platform!');В коді можемо подивитися невеликий приклад SRP в дії. Ми маємо бізнес задачу - реєструвати юзера і відправлять йому імейли. Початково під час розробки є бажання інкапсулювати цю фічу просто в один клас (функцію). Тобто юзер би і дані юзера записував і імейли відправляв. Але це порушує SRP. По перше, в User більше однієї зони відповідальності (і юзер і імейли). По-друге, в нього більше однієї причини для зміні - щось змінилося в логіці реєстрування юзера або змінилися реквайременти для емейлів. Розділяючи це на два класи, ми дотримуємося SRP. Можна ще створити RegistrationService який би керував процесом реєстрації за допомогою цих двох класів.
Антипатерном принципу Single Responsibility є God Object. Це коли один клас (об’єкт) знає про всю логіку великої фічі/додатку.
