چرا کلاس ها

این راهنما تا به اینجا کاملاً واقع‌بینانه و عمل‌گرایانه پیش رفته است؛ ما روی نحوه استفاده از کلاس‌ها تمرکز کردیم، اما یک سوال مهم هنوز بی‌پاسخ مانده است: اصلاً چرا باید از کلاس‌ها استفاده کنیم؟ پاسخ این است: بستگی دارد!

کلاس‌ها یک پارادایم (Paradigm) یا روشی جدید برای سازماندهی کدهای شما معرفی می‌کنند. آن‌ها فونداسیون و پایه‌ی برنامه‌نویسی شیء‌گرا (OOP) هستند که بر مفاهیمی مانند ارث‌بری (Inheritance) و چندریختی (Polymorphism) بنا شده است. با این حال، بسیاری از توسعه‌دهندگان از نظر فلسفی با برخی از روش‌های شیء‌گرایی مخالف هستند و در نتیجه ترجیح می‌دهند اصلاً از کلاس‌ها استفاده نکنند.

چالش‌های پارادایم شیء‌گرا

یکی از دلایلی که برای مثال اشیاء Date را بدنام کرده، تغییرپذیر بودن (Mutable) آن‌هاست:

function incrementDay(date) {
  return new Date(date.setDate(date.getDate() + 1));
}

const date = new Date(); // فرض کنیم امروز 2019-06-19 است
const newDay = incrementDay(date);

console.log(newDay); // خروجی: 2019-06-20
// تاریخ قبلی هم تغییر کرده است؟!
console.log(date);    // خروجی: 2019-06-20

تغییرپذیری (Mutability) و مدیریت وضعیت داخلی (Internal state) از جنبه‌های مهم برنامه‌نویسی شیء‌گرا هستند، اما اغلب تحلیل و درک کد را سخت می‌کنند؛ زیرا یک عملیات به ظاهر بی‌خطر در یک گوشه از برنامه، می‌تواند عوارض جانبی (Side effects) غیرمنتظره‌ای داشته باشد و رفتار بخش‌های دیگر را تغییر دهد.

همچنین برای استفاده مجدد از کدها در این پارادایم، ما معمولاً به ارث‌بری کلاس‌ها روی می‌آوریم که این کار می‌تواند سلسله‌مراتب بزرگی از الگوهای ارث‌بری پیچیده ایجاد کند. از طرفی، توصیف تمیزِ ارث‌بری زمانی که هر کلاس فقط می‌تواند از یک کلاس دیگر ارث‌بری کند (Single inheritance)، بسیار دشوار است.

ما اغلب دوست داریم رفتار چند کلاس مختلف را هم‌زمان داشته باشیم. در زبان جاوا این کار از طریق اینترفیس‌ها (Interfaces) انجام می‌شود و در جاوااسکریپت می‌توان آن را با Mixins پیاده‌سازی کرد؛ اما در نهایت، این روش‌ها هنوز هم چندان راحت و بی‌دردسر نیستند.

مزایا و نقاط قوت کلاس‌ها

اما از زاویه‌ای مثبت‌تر، کلاس‌ها روشی بسیار قدرتمند برای سازماندهی کدهای ما در سطوح بالاتر ارائه می‌دهند. به عنوان مثال، اگر کلاس Color را نداشتیم، مجبور بودیم ده‌ها تابع کمکیِ پراکنده بسازیم:

function isRed(color) {
  return color.red === 255;
}

function isValidColor(color) {
  return (
    color.red >= 0 &&
    color.red <= 255 &&
    color.green >= 0 &&
    color.green <= 255 &&
    color.blue >= 0 &&
    color.blue <= 255
  );
}
// و توابع کمکی دیگر...

اما با کمک کلاس‌ها، می‌توانیم تمام این توابع را زیر چتر و فضای نامِ (Namespace) اختصاصی Color جمع کنیم که این کار خوانایی برنامه را به شدت بالا می‌برد. علاوه بر این، معرفی فیلدهای خصوصی (Private fields) به ما اجازه می‌دهد داده‌های حساس را از دید کاربرانِ بعدی کدمان مخفی کنیم و یک API تمیز و استاندارد تحویل دهیم.

چه زمانی باید از کلاس‌ها استفاده کنیم؟

به طور کلی، زمانی باید به سراغ استفاده از کلاس‌ها بروید که می‌خواهید اشیائی بسازید که داده‌های داخلی خود را ذخیره کنند و در عین حال رفتارها و متدهای زیادی را ارائه دهند. کلاس‌های داخلی خودِ جاوااسکریپت بهترین نمونه‌ها برای درک این موضوع هستند:

• کلاس‌های Map و Set: مجموعه‌ای از عناصر را ذخیره می‌کنند و به شما اجازه می‌دهند با استفاده از متدهایی مثل ()get ،set() ،has() و غیره به آنها دسترسی داشته باشید.

• کلاس Date: یک تاریخ را به صورت برچسب زمانی یونیکس (یک عدد) ذخیره می‌کند و متدهایی برای فرمت‌دهی، به‌روزرسانی و خواندن اجزای فردی تاریخ در اختیارتان می‌گذارد.

• کلاس Error: اطلاعات مربوط به یک استثنای خاص (Exception)، از جمله پیام خطا، ردپای پشته (Stack trace) و علت خطا را ذخیره می‌کند. این کلاس یکی از معدود ساختارهای داخلی است که همراه با یک ساختار ارث‌بری غنی عرضه می‌شود؛ کلاس‌های داخلی متعددی مانند TypeError و ReferenceError وجود دارند که Error را اکستند می‌کنند. این ارث‌بری به دقیق‌تر شدن معنای خطاها کمک می‌کند و می‌توان نوع آن‌ها را به راحتی با instanceof بررسی کرد.

در نهایت، جاوااسکریپت مکانیسم سازماندهی کدها به روش استاندارد شیء‌گرا را در اختیار شما می‌گذارد، اما اینکه آیا از آن استفاده کنید یا نه و چگونه آن را به کار بگیرید، کاملاً به تصمیم و سلیقه شما به عنوان یک برنامه‌نویس بستگی دارد.