پرش به مطلب اصلی

یک پست با برچسب "مسئولیت یکتا"

یادداشت‌هایی درباره اصل مسئولیت یکتا و دلیل تغییر

مشاهده تمام برچسب‌ها

مسئولیت یکتا یعنی یک دلیل برای تغییر، نه فقط یک تابع کوچک‌تر

· ۹ دقیقه مطالعه
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

یک کلاس در مرکز که از چند سمت با خواسته‌های مالی، نمایشی، ذخیره‌سازی و گزارشی کشیده می‌شود.

فرض کنید در یک سامانه‌ی مالی، کلاسی داریم که در نگاه نخست کار ساده‌ای انجام می‌دهد: اطلاعات یک پرداخت را می‌گیرد و آن را پردازش می‌کند. اما کمی که به درونش نگاه می‌کنیم، می‌بینیم این کلاس هم قانون مالی را محاسبه می‌کند، هم خروجی رابط برنامه‌نویسی کاربردی (API) را می‌سازد، هم داده را در پایگاه داده ذخیره می‌کند.

class PaymentService {
async process(payment: Payment) {
const fee = payment.amount * 0.01
const finalAmount = payment.amount - fee

const savedPayment = await db.payments.insert({
userId: payment.userId,
amount: payment.amount,
fee,
finalAmount,
status: 'done',
})

return {
id: savedPayment.id,
amount: savedPayment.amount,
fee: savedPayment.fee,
finalAmount: savedPayment.finalAmount,
message: 'پرداخت با موفقیت انجام شد',
}
}
}

این کلاس شاید کوتاه باشد. شاید فقط یک تابع عمومی داشته باشد. شاید حتی در بازبینی کد کسی بگوید: «فعلاً که پیچیده نیست.» اما مسئله‌ی اصل مسئولیت یکتا از جای دیگری آغاز می‌شود. پرسش اصلی این نیست که کلاس چند تابع دارد؛ پرسش این است که این کلاس به چند دلیل متفاوت ممکن است تغییر کند.