شی گرایی، از حرف تا عمل

توضیح: من در حال انتقال بلاگم هستم، برای همین نوشته‌های قبلیم در حال حاضر در دسترس نیستن ولی در روزهای آینده اون ها رو هم به بلاگ اضافه میکنم.

---

تب برنامه‌نویسی فانکشنال این روزها بسیار بالاست. برنامه نویسی فانکشنال از قدیمی‌ترین شیوه‌های برنامه نویسی هست، اما اکثر برنامه‌نویس‌ها به تازگی بهش گرایش پیدا کردن؛ و مثل هر چیز جدیدی که از راه می‌رسه، حسِ «نو که میاد به بازار، کهنه میشه دل آزار» رو در دل خیلی ها جا انداخته. و احتمالا حدس میزنید که در این ضرب المثل، «شی گرایی» نقش «کهنه» رو بازی می‌کنه!

به همین دلیل هم اگر دقت کرده باشین، جدیدا مطالب زیادی در باب مقایسه‌ی بین شی‌گرایی و برنامه‌نویسی فانکشنال روی وب می‌بینید. اکثر این مطالب هم حاوی نقدهایی هست که به شی‌گرایی وارد میشه. اینکه شی گرایی چقدر بده، چقدر سخته، چقدر ناکارآمده و …

البته طبق اون ضرب المثلی که عنوان کردیم این واکنش طبیعی هست! یعنی این نقطه نظرات منفی نسبت به شی گرایی تا حد زیادی به خاطر شوق و ذوق آشنا شدن برنامه نویس‌ها با یک چیز جدیده؛ به عبارتی، «جو گیر» شدن برنامه نویس ها! به همین خاطر خیلی از حرف‌ها و بحث‌هایی که در این باره پیش میاد دقیقا با واقعیت برابر نیست. همونطور که می دونیم، جوگرفتگی یک سیر صعودی داره و یک سیر نزولی! در حال حاضر، جوگرفتگیِ حاصل از برنامه نویسی فانکشنال در حال طی کردن سیر صعودی خودش هست، اما بعد از یه مدت این آتیش هم می خوابه و کم کم سیر نزولی اش شروع میشه. اون موقع هست که باید از خودمون سوال کنیم آیا نسبت به این مباحث درست تصمیم گرفتیم؟ آیا با فکر و منطق عمل کرده بودیم؟

اجازه بدید تجربه‌ی شخصی خودم رو براتون تعریف کنم:

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

هر چی بیشتر شی گرا کار میکردم، حس میکردم به جای اینکه ساختار کدهام بهتر بشه، داره پیچیده تر میشه! به جای اینکه اجزای مختلف برنامه ام مستقل تر بشن، دارن بیشتر به هم تنیده میشن! و وقتی می خواستم از قسمتی از کدهام تو پروژه ها دیگه استفاده کنم، کلی باید دنگ و فنگ متحمل میشدم… یه چیزی این وسط درست نبود…

کلی کتاب از نویسندگان معروف و به نام خونده بودم. کلی بلاگ و مطالب جور واجور مطالعه کرده بودم، از برنامه نویس هایی که خیلی از من حرفه ای تر بودن… همه دانسته ها و دانشی که کسب کرده بودم این رو به من میگفتن که به کمک برنامه نویسی شی گرا قراره کدنویسی بهتر بشه. اما در عمل من نه تنها این حس رو نداشتم، بلکه برعکس فکر میکردم شی گرایی خودش داره برام مشکل ساز میشه!

ممکن بود مشکل از من باشه. شاید این من بودم که به درستی شی گرایی رو پیاده سازی نمیکردم. شاید یک سری قوانین شی گرایی رو به خوبی توی پروژه هام اعمال نمیکردم… اما نه، فقط من نبودم! وقتی از کتابخونه های جانبی استفاده میکردم، متوجه میشدم بقیه برنامه نویس ها هم کم و بیش گرفتار همچین قضیه ای هستن. هر کتابخونه ای که میخواست خیلی شی گرا باشه، به شکل ملموسی از بقیه کتابخونه ها پیچیده تر بود… هر چه شی‌گرا تر، پیچیده‌تر!

گاهی کدهای این کتابخونه‌هارو مطالعه میکردم. متوجه میشدم کدی که اون برنامه نویس نوشته و توش ۵-۶ تا کلاس تعریف کرده، میتونست خیلی راحت با ۲-۳ تا تابع ساده هم نوشته بشه! از خودم سوال میکردم: آیا این پیچیدگی دلیل خاصی داشته، یا اینکه برنامه نویس فقط و فقط به صرف اینکه اصرار داشته کدهاش رو به شکل شی گرا بنویسه این پیچیدگی رو به جون خریده؟

کم کم متوجه شدم حسی که نسبت به شی گرایی دارم ممکنه خیلی هم بیراه نباشه! شی گرایی واقعا یک سری پیچیدگی هایی رو با خودش وارد پروژه میکنه که میتونه از پایه و اساس وجود نداشته باشه. به این نتیجه رسیدم که شی گرایی بیشتر از اینکه درمانی برای مشکلات باشه، در واقع درمانی برای مشکلاتی هست که خودش به وجود میاره! مثل اینه که یک شرکت داروسازی خودش یک بیماری رو در جامعه شیوع بده، و بعد خودش بیاد برای اون بیماری دارو بسازه! حداقل این حسی بود که در اون زمان داشتم (و هنوز هم بعد گذشت چندین سال این حس رو دارم…)

تشدید این حسی که نسبت به شی‌گرایی پیدا کرده بودم، همزمان شده بود با علاقه‌مند شدن من به برنامه‌نویسی همروند. در اون زمان (و حتی همین روزها) پایتون پشتیبانی خیلی جالبی از برنامه‌نویسی همروند ارائه نمی‌داد. همه این ها باعث شد من جستجویی رو شروع کنم برای راه حل‌های آلترناتیو…

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

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

میزان سادگی و راحتی مدل فانکشنال در برابر شی‌گرایی به شکل قابل توجهی برام مشهود بود؛ اما هنوز موردی پیش نیومده بود که بخوام واقعا ایده های فانکشنال رو به کار ببرم. تا اینکه یه روز به شرکتی سر زدم که یک سال قبل براشون برنامه‌ای نوشته بودم. متوجه شدم توی این یک سال، طرز استفاده و همچنین میزان استفاده ای که از برنامه داشتن دقیقا چیزی نبوده که من پیش بینی می‌کردم. حس کردم که برنامه می‌تونه یک سری تغییراتی داشته باشه تا برای کار اون ها مناسب تر باشه. این به فکر به ذهنم خطور کرد که چه فرصتی بهتر از این؛ می‌تونم کدهای شی‌گرایی که نوشته بودم رو به شکل فانکشنال بازنویسی کنم. درسته، زحمت داشت و من هم هیچ پولی برای این بازنویسی ازشون دریافت نمیکردم، ولی در آخر می تونستم بفهمم که مدل فانکشنال تو پروژه‌ی واقعی چجوری جواب میده…

خوب همونطور که گفتم، تصمیم گرفته بودم از همون پایتون استفاده کنم، ولی ایده‌ها و الگوهای فانکشنال رو در کدهام اعمال کنم:

• هیچ کلاس و شی ای تعریف نکردم.
• هیچ متغیر یا ساختار سراسری وجود نداشت.
• موقع باز کردن سورس فایل ها، از بالا تا پایین فقط توابع دیده میشدن.
• توابع تا جایی که امکان داشت کوچیک تعریف شدن (بیشترشون زیر ۵ خط بودن!)
• تمام توابع مقداری رو برگشت می دادن؛ حتی توابعی که واقعا نیازی به برگشت دادن مقداری نداشتن!
• وظایف بزرگ به وظایف کوچیک‌تر تقسیم شده بودن و هر کدوم در غالب یه تابع ظاهر شده بودن.
• به جای داشتن توابع ۳۰-۴۰ خطی، سعی می‌کردم ۵-۶ تا تابع ۵-۶ خطی رو مثل زنجیر بهم متصل کنم تا به کمک هم وظایف بزرگتر رو انجام بدن.
• تمام عملیات مربوط به IO در توابع کاملا مشخص محصور شده بودن.
• تا جایی که می تونستم سعی کردم از داده‌ها به شکل ثابت استفاده کنم. (ایموتیبل)
• تا جایی که تونستم سعی کردم معماری کدهام «تهی از وضعیت»(Stateless) باشه تا وابستگی بین اجزای کدهام کمتر شه
• . . .

با اینکه پایتون یک زبان فانکشنال نیست و من فقط یک سری از ایده‌هایی برنامه‌نویسی فانکشنال رو در کدهام اعمال کرده بودم، اما نتیجه‌ی کار عالی بود! هم برنامه‌نویسی خیلی برام راحت تر شده بود و هم عیب یابی کدهام. هنوز هم بعد از مدت ها وقتی میرم و اون کدها رو می‌بینم، خیلی راحت متوجه شون میشم. این تجربه‌ای نیست که بتونم با کدهای شی‌گرایی در قدیم نوشتم داشتم باشم!

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

حالا این یعنی برنامه‌نویسی شی‌گرا بده؟ برای من برنامه‌نویسی فانکشنال درک اش ساده‌تره. راحت‌تره. و از همین رو درصد خطای من رو در برنامه‌نویسی کاهش میده. اما نمی‌تونم بگم برنامه‌نویسی شی‌گرا بده. همونطور که نمی تونم بگم شی‌گرایی بهتره! این‌ها، دو طرز فکر درباره چگونگی پیاده‌سازی برنامه‌ها هستن.

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

اکثر برنامه‌نویس‌هایی که من می‌شناسم حتی تعریف درستی از شی‌گرایی نمی‌تونن ارائه بدن! همون ۴تا کلمه‌ای که تو کتاب‌های ترجمه شده‌ی فارسی از شی‌گرایی یاد گرفتن رو طوطی وار تکرار میکنن بدون اینکه مفهوم شی‌گرایی رو واقعا در کنن. جو آرمسترانگ (خالق ارلنگ) معتقده ارلنگ «تنها» زبان واقعا شی‌گرا هست که در حال حاضر به شکل گسترده استفاده میشه! یه برنامه‌نویس معمولی وقتی اینو بشنوه هنگ میکنه! مگه ارلنگ یه زبان فانکشنال نیست، چجوری این آقا همچین حرفی میزنه؟ پس جاوا و سی پلاس پلاس و بقیه چی؟ وقتی دنبال جواب این سوالات برید تازه متوجه می‌شید اتفاقا ایشون خیلی هم بی ربط حرف نمیزنه و داستان شی‌گرایی از اون داستان هاست که سر دراز داره و خیلی چیزها هست که هنوز درباره اش نمی‌دونید…

نقطه‌ی قوت برنامه‌نویسی فانکشنال سادگی اون هست. برنامه‌نویسی فانکشنال رو میشه در یک جمله تعریف کرد:

«برنامه‌نویسی فانکشنال مدلی از برنامه‌نویسی است که در آن عمل تخصیص مقادیر وجود ندارد.» (مثل عملگر = در زبان‌های خانواده‌ی سی)

به همین سادگی! جمله‌ی بالا، تمام تعریفی هست که برای بیان برنامه‌نویسی فانکشنال نیاز دارید!

زوایای دیگه‌ای هم که در برنامه‌نویسی فانکشنال می‌بینید از همین یک خط تعریف ناشی میشن:

• چون عمل تخصیص وجود نداره، بنابراین متغیری در کار نیست. (ایموتیبل بودن داده‌ها)
• چون متغیری درکار نیست، همه چیز در غالب «تناظر» (Match) بیان میشه.
• چون عمل تناظر نیاز به محسابه‌ی مقادیر داره، همه‌ی کدها حالت Expression دارن. (کدی که حتما مقداری رو برمی‌گرداند)
• چون کدها حالت اکسپرشن دارن، یعنی همه‌شون در واقع در قالب توابع بیان شده اند (حلقه‌ها، شر‌ط‌ها، ساختارهای داده، حتی اعداد…)
• چون کدها به شکل توابع ظاهر میشن، و توابع هم متغیر نیستند، پس عمل تخصیص وجود نداره (تعریفی بازگشتی که شمارو به ابتدای لیست میبره!)

اینجا می‌تونیم یه تعریف دیگه هم از برنامه‌نویسی فانکشنال ارائه بدیم:

«برنامه‌نویسی فانکشنال مدلی از برنامه‌نویسی است که در آن همه چیز یک تابع است»

برنامه‌نویسی فانکشنال بر مبنای «محاسبات لاندا» بنا شده. با ارائه نظریه محاسبات لاندا، «آلونزو چِرچ» ثابت کرد که میشه تمام محاسبات ریاضی رو در قالب توابع بیان کرد. خوبی این نظریه این بود که یک قانون خیلی ساده داشت: همه چیز تابع است!

برنامه‌نویسی فانکشنال هم همینطوره. سادگی مدل فانکشنال برای اینه که این مدل برنامه‌نویسی فقط یک قانون داره: همه چیز تابع است؛ بر مبنای همین یک قانون ساده، شما چه کارها که نمی‌تونید بکنید.

حالا اگه بخوایم شی‌گرایی رو تعریف کنیم چی؟ باید چند صحفه فقط به تعریف‌اش اختصاص بدیم.

برای مثال بیایید یکی از پیشنهاد‌های سودمند مربوط به شی‌گرایی رو باهم مرور کنیم. تو این مثال از جاوا کمک می‌گیریم. اگر یک کتاب باشه که شما به عنوان جاوا کار باید حتما اون رو مطالعه کرده باشید، اون کتاب معروف Effective Java هست نوشته‌ی Joshua Bloch. این کتاب کلمه به کلمه‌اش و سطر به سطرش باعث بهتر شدن شما به عنوان یک جاوا کار میشه. توی این کتاب چنین چیزی گفته شده:

«...کلاس‌ها باید حتما به شکل ایموتیبل تعریف شوند، مگر اینکه دلیل خیلی قانع کننده‌ای برای موتیبل تعریف کردن آن‌ها داشته باشید...اگر امکان این را نداشته باشید که کلاس را کاملا ایموتیبل بسازید، تا جایی که امکان دارد عناصر موتیبل را محدود نمایید...»

خوب حالا اگر بخوایم در جاوا به این پیشنهاد عمل کنیم باید چه کارهایی انجام بدیم؟

• کلاس را به شکل final تعریف کنیم.
• تمام فیلدها باید final و private باشند.
• فیلدها فقط باید از طریق سازنده‌ی کلاس مقدار دهی شوند.
• هیچ متدی که عملیات set روی فیلدها انجام دهد نباید وجود داشته باشد.
• هیچ متدی از متدهای کلاس نباید فیلدها را تغییر دهند.
• …

این دیگه چجور پیشنهادیه؟ آیا اصلا میشه به این شکل با جاوا برنامه‌نویسی کرد؟ بله، میشه. اتفاقا اگر به این پیشنهاد عمل کنید کلی از دردسرهاتون کم میشه. از تاثیرات جانبی این پیشنهاد اینه که چون دست متدها برای ویرایش فیلدها بسته است، بنابراین مجبور میشید تعداد متدهای کلاس رو کم کنید. وقتی مجور بشید متدهای یک کلاس رو کم کنید، یعنی در حال کوتاه کردن هرچه بیشتر شاخ و برگ‌های کلاس هستید و کلاس تک وظیفه‌ای میشه؛ در نهایت شاید در هر کلاس یک سازنده به علاوه‌ی یک یا دو متد دیگه داشته باشید. هر چه کلاس به سمت تک وظیفه‌ای شدن پیش بره و خلوص بالاتری پیدا کنه، مستقل‌تر میشه و در نهایت معماری کدهاتون هم بهتر میشه. از طرفی میشه با خیال راحت تری چنین کلاس‌هایی رو در برنامه‌نویسی همروند شرکت بدیم.

حالا سوال من از شما اینه: چند پروژه‌ی معروف جاوا دیدید که به این پیشنهاد عمل کنن؟ اصلا پروژه‌های معروف به کنار، چند تا از همکارهای شما این مدلی برنامه‌نویسی میکنن؟ خودتون چند بار پیش اومده که اینطور برنامه‌نویسی کنید؟

همونطور که می‌بینید شی‌گرایی کاملا قابلیت این رو داره تا علاوه بر اینکه باعث ساختار بهتر کدها بشه، بتونه در برنامه‌نویسی همروند هم خیلی خوب ظاهر بشه؛ اما متاسفانه این امکان هم هست که به آسونی کدهای شما به آش شله قلمکار تبدیل بشه! عین اینه که برای رفتن از تهران به شیراز دوتا جاده داشته باشیم، یکی خاکی و اون یکی کاملا صاف و آسفالت؛ اما راهنمایی و رانندگی تابلوی «به طرف شیراز» رو جوری نصب کرده باشه که جاده‌ی خاکی رو به شما نشون میده! شی‌گرایی عین همینه؛ توش جاده‌ی صاف و آسفالت هم داره، ولی همه‌ی چیز شما رو به رد شدن از جاده‌ی خاکی ترغیب میکنه!

دلیل چنین قضیه‌ای اینه که در زبان‌های معروف شی‌گرا، شی‌گرایی به شکلی که واقعا باید پیاده‌سازی می‌شد ارائه نشده. «آلن کای» از نامدارترین افراد دنیای کامپیوتر، کسی هست که واژه‌ی «شی‌گرایی» رو در دنیای کامپیوتر جا انداخت. وقتی ازش پرسیده میشه منظورش واقعا از شی‌گرایی چیه، این جوابی هست که میده:

«...من آبجکت‌هارو به شکل سلول‌های بیولوژیکی، یا کامپیوترهای مستقل‌ای که در یک شبکه قرار دارن تصور می‌کنم؛ که تنها راه ارتباط اون‌ها با هم از طریق «انتقال پیام» هست...»

جالب اینه که این نظریه بعد از مطالعه‌ی زبان «لیسپ» به ذهن‌اش رسیده! و اولین پیاده‌سازی از چیزی که به عنوان شی‌گرایی در نظر داشته رو هم با لیسپ انجام داده. در نهایت سخنانش رو جمع بندی میکنه و میگه:

«شی‌گرایی از نظر من تنها یعنی «پیام‌ها» (روش انتقال پیام)، نگه‌داری و محافظت و مخفی کردن وضعیت هر پروسه از دیگر پروسه‌ها، و late-binding برای همه چیز است.»

قبل از هر چیز بذارید late-binding رو توضیح بدم: late-binding یعنی داده‌ها و عناصر مختلف برنامه تا جایی که امکان داره و تا قبل از زمان اجرای برنامه، از وضعیت بعدی خودشون با خبر نباشن. به عبارت دیگه: داینامیک بودن زبان. مشابه پایتون، روبی، لیسپ،… همینجا اولین مورد نامتعارف خودش رو نشون میده: اکثر زبان‌های شی‌گرای معروف مثل جاوا، سی ‌پلاس‌پلاس، یا سی‌شارپ، همشون استاتیک تایپ هستن! یعنی دقیقا بر عکس چیزی که آلن کای در نظر داشت!

یه بار دیگه بررسی کنیم که آلن کای چی گفت:

• انتقال پیام
• کنترل وضعیت و مستقل بودن پروسه‌ها از هم
• داینامیک بودن زبان

با توجه تعاریف بالا، اولین زبانی که به ذهن‌تون می‌رسه چیه؟ ارلنگ! یادتونه جو آرمسترانگ چی گفته بود؟ قضیه جالب شد :)

در زبان‌هایی مثل ارلنگ، گولنگ، کلوژور، الیکسیر، هسکل و … شما می‌تونید تعریف آلن کای از شی‌گرایی رو داشته باشید. جالب‌تر اینکه هیچ کدوم این زبان‌ها شی‌گرا نیستن! ولی از اون زبان‌هایی که ادعای شی‌گرایی می‌کنن بهتر امکان شی‌گرایی بهتون ارائه میدن! متاسفانه عده ای فکر میکنن وجود ساختاری مثل «کلاس» یعنی شی‌گرایی. اینکه یک بسته‌ای داشته باشیم و بتونیم فیلدها و متدهامون رو توش بریزیم و همه شون رو یه جا مدیریت کنیم. نه، این چیزی که در نظر شماست یعنی استفاده ‌از کلاس فقط به عنوان یک «فضای نام»! کلاس به تنهایی فقط یک سینتکس راحت‌تر برای struct هایی هست که از اول هم در C وجود داشت. مفهوم شی‌گرایی خیلی بیشتر از وجود کلاس‌هاست…

خود زبان‌های شی‌گرا هم تا جایی که میتونن به دلیل نامعلومی سعی در پیچیده کردن مدل شی‌گرایی دارن! نمونه‌ی بارزش مکانیزم «وراثت» هست. وراثت پر حاشیه‌ترین و مورد انتقادترین عنصر شی‌گرایی هست. شاید بشه گفت یکی از دلایل اصلی پیچیدگی شی‌گرایی همین وراثت هست. جاوا سعی کرد وراثت چندگانه رو که در سی‌پلاس‌پلاس وجود داشت ارائه نده و تا حدی باعث ساده تر شدن این قضیه بشه اما در عمل میبینیم وراثت باز هم یه ویروس ضرر خودش رو به سیستم میزنه. حتی در کتاب Design Patterns که به GoF معروف هست و به نوعی انجیل برنامه‌نویسی شی‌گرا محسوب میشه هم به این قضیه اشاره شده که ترکیب‌کاری (Composition) رو همیشه به وراثت ترجیح بدید…

در یک نمونه‌ی دیگه، میشه کالکشن‌ها اسکالا رو با کلوژور مقایسه کرد. کلوژور به عنوان یک زبان فانکشنال، در برابر اسکالا به عنوان زبانی که تصمیم گرفت علاوه بر فانکشنال بودن، شی‌گرا هم باشه. کاکلشن‌های اسکالا رو ببینید:

• یک گروه ایموتیبل هستن
• یگ گروه موتیبل هستن.
• یک گروه همروند هستن.
• یک گروه ایموتیبل هستند و موازی.
• یک گروه موتیبل هستند و موازی.

از اونور کلوژور چی؟ یه سری کالکشن ساده و یکپارچه داره که هم میشه به صورت عادی و غیر همورند ازشون استفاده کرد، هم به شکل همورند، هم در محاسبات موازی شرکت شون داد. دیگه این همه دنگ و فنگ نداره. این چیزی بود که «ریچ هیکی» هم یکبار در یکی از کنفرانس‌ها بهش اشاره کرد و با خنده‌ی شنوندگان همراه شد. من کالکشن‌های اسکالا رو مطالعه نکردم و واقعا نمی دونم دلیل شون برای اینکار چی بوده، اما می‌تونم یه حدس بزنم: اینکه تایپ سیستم استاتیک زبان و وارد کردن طراحی شی‌گرا باعث همچین چیزی شده. باز هم طراحی شی‌گرا کار خودش رو کرده و باعث پیچیدگی شده…

این بحث چیزی نیست که بشه در یک پست وبلاگی در موردش صحبت کرد. برنامه‌نویس‌ها باید خودشون درباره شی‌گرایی و نقاط قوت و ضعف اش مطالعه کنن. همچنین باید مدل ‌های آلترناتیو مثل مدل فانکشنال رو هم مورد بررسی قرار بدن تا با در کنار هم قرار دادن داده‌هایی که بدست میارن بتونن یه برداشت درست از این مباحث پیدا کنن.

در نهایت می تونم دانسته‌ها، دانش، و تجربیات شخصی خودم در این زمینه رو به این شکل جمع بندی کنم:

• شی‌گرایی به عنوان یک روش پیشنهادی، پیچیدگی هایی رو با خودش به همراه میاره.
• اکثر زبان‌های شی‌گرا، اونطور که می‌بایست شی‌گرایی رو پیاده‌سازی نکردن.
• شی‌گرایی می تونه در هر زبانی به کار گرفته بشه (حتی زبان‌های غیر شی‌گرا)
• شی‌گرایی می‌تونه در برنامه‌نویسی همروند خوب عمل کنه، ولی اصلا برای اینکار بهینه نیست.
• اکثر برنامه‌نویس‌های شی‌گرا، درک خیلی درست و جامعی از شی‌گرایی ندارن.
• تعداد زیادی از برنامه‌نویس‌های شی‌گرا، اصول و پیشنهادهای سودمند مربوط به شی‌گرایی رو رعایت نمیکنن.
• خیلی از پیشنهادها یا دیزاین پترن‌ها هستند که اتفاقا باعث پیچیده‌تر شدن شی‌گرایی میشن.
• مهم ترین مزیت مدل مدل فانکشنال به شی‌گرایی، ساده‌تر بودن اون هست.
• از محبوبیت شی‌گرایی به این راحتی ها کم نمیشه، چون یادگیری مدل‌های دیگه مثل(فانکشنال) نیاز به آموزش دوباره داره.
• با وارد شدن ایده‌های فانکشنال به زبان‌های شی‌گرا (برای نمونه جاوا ۸)، این زبان‌ها تا حدی وضعیت بهتری پیدا خواهند کرد.
• هیچ قانونی وجود نداره که زبان‌های شی گرا مقداری فانکشنال بودن به زبان وارد نکنن، یا برعکس.
• برنامه‌نویس‌ها دنبال چیزهای «بهتر» نمیرن، دنبال چیزهای «ساده‌تر» میرن!
• برنامه‌نویس‌ها دنبال چیزهای «ساده‌تر» نمیرن، دنبال چیزهای «آشناتر» میرن!