از اونجایی که توی این بحث، به کتابچهای که من نویسندهاش بودم اشاره شده، شاید بد نباشه من هم چند خط توضیح راجع به شیگرایی بدم.
واژهی «شیگرا» یا object-oriented واژه ایی هست که Alan Kay ابدا کرد. اگر این آقا رو نمیشناسید، عین کسی هستید که فوتبال دوست داره
ولی رونالدو رو نمیشناسه! اول یه توضیحی بدم که این آقا کی هست:
- یکی از بزرگترین و موثرترین افراد در علوم کامپیوتر
- پرفسور دانشگاه MIT
- از هکرهای معروف LISP
- از افرادی که زبان Smalltalk رو بنا کردند
- موثرترین فرد در توسعهی ایدهی Laptop و GUI
- برندهی جایزهی ACM Turing (معادل نوبل در علم کامپیوتر) و جایزهی Kyoto Prize
- جملهی معروف The best way to predict the future is to invent it هم از ایشون هست.
خوب حالا برسیم به بحث اصلی. ایشون در اصل ایدههای شی گرایی رو در زبان lisp پیادهسازی کردن و در واقع از خود این زبان الهام گرفتن این
ایده رو. اگه با lisp آشنا نباشید واقعا چیز زیادی از برنامهنویسی نمیدونید!! بعدها تمام اون ایدهها رو به صورت شسته رفته تر در زبان
جدیدی به اسم Smalltalk پیاده سازی کردن. وقتی ازشون در یک ایمیل سوال شده بود موقع کار روی ایدهی شی گرایی توی فکرتون چه چیزی بوده
دقیقا، ایشون اینطوری جواب دادن [1]:
«من یک object رو به صورت سلولهای بیولوژیک، و یا کامپیوترهای مستقلی که در یک شبکه قرار دارن تصور میکنم که تنها راه ارتباط اونها با
هم از طریق انتقال پیام هست...»
پس هر آبجکت کاملا مستقل هست، و از طریق انتقال پیام با بقیه آبجکت ها در اتباط هست. قضیه کپسوله سازی هم در حقیقت به مستقل بودن یک
آبجکت اشاره میکنه نه اینکه فیلدهای یک آبجکت به صورت خصوصی باشه و به زبون دیگه مخفی سازی صورت بگیره. این دقیقا همون «برنامهنویسی
همروند» یا Concurrent هست، به حالتی که از شیوهی انتقال پیام یا Message Passing برای ارتباط بین اجزای همروند برنامه استفاده بشه.
زبانهایی مثل Go, Erlang, Haskell, Scala, Clojure به بهترین شکل قادر به برنامهنویسی با چنین شیوه ایی هستن. اگه دقت کنید به غیر از
Go، بقیه شون در واقع Functional هستن! اگه گاهی در جایی میخونید که این زبان ها، اتفاقا جزو بهترین زبان های شیگرا هستن، قضیه همینه!
اگه دقت کنید این زبانها خودشون رو به عنوان زبانهای Concurrent معرفی میکنن. زبانی که ذاتا Concurrent هست دیگه نیازی به شیگرا بودن
نداره چون در واقع به حالت عادی شیگرا هست!!! اما نه اون شیگرایی که در بین عام برنامهنویسان جا افتاده. اون شیگرایی که خود Alan Kay
در نظر داشت به بهترین نحو در Go و Erlang پیاده سازی شده. در جایی دیگه هم Alan Kay میگه مهم ترین عنصر شیگرایی در واقع مفهوم انتقال
پیام هست....
حالا همین جا دست نگه دارید و یه توضیح دیگه رو گوش کنید:
در همون روزهای اولیه شیگرایی، زبان دیگه ایی به اسم Simula در حال توسعه بود که برای ساخت برنامههای شبیهسازی در نظر گرفته شده بود. Simula با قسمتهای مجزای کد مانند اشیای دنیای واقعی برخورد میکرد (به هر حال برای شبیه سازی ساخته شده بود!). هر شی میتونه تعدادی
خصیوصیت داشته باشه، و تعدادی رفتار... این توضیحات برای شما آشنا نیست؟ این چیزی هست که در بین عام برنامهنویسان جا افتاده. دلیلش؟
زبان ++C به عنوان اولین زبان شیگرای موفق، از نگرش Simula برای ایدههای شیگرایی استفاده کرد.بعد از اون هم Java دنبال روی ++C شد و دو
تایی به عنوان قدرتهای اول شیگرایی شناخته شدن. بقیه زبانها هم مثل Python یا PHP راه Java و ++C رو ادامه دادن. حتی چیزهایی مثل کلاس یا
زیرکلاس در حقیقت از Simula اومده. در واقع اصلا لازم نیست یک زبان شی گرا حتما دارای ساختار class باشه، این روش فکری simula بوده و دلیل نمیشه همه باهاش موافق باشن. و این شد که اکثر زبانهایی که امروزه به عنوان زبانهای شی گرا میشناسید، بر پایهی ایده های اصلی Alan Kay
شکل نگرفتن. هر چند که بعد ها به مرور زمان خیلی از این ایده ها با هم مخلوط شدن اما در بطن خودشون از اساس با هم فرق دارن.
حالا شما قضاوت کنید: با این همه مباحث مربوط به کپسوله سازی، اجزای یک برنامه در Java مستقل تر هستن یا اجزای یک برنامه در Clojure ؟
حتی مقایسهی جاوا با چیزی مثل Clojure یا Haskell در این زمینه خنده داره.
یا با این همه مانور روی استفاده مجدد از کد، آیا کلاسهای نوشته شده در جاوا قابلیت استفادهی مجدد راحت تری رو دارن یا توابع کوچکی که در
Clojure و Haskell ایجاد میکنین؟
یا یک زبانی مثل Go رو در نظر بگیرید. افراد پشت این زبان حرفشون اینه: مگه ساختار class و مباحث مربوط به اون همون چیزی نبود که شما
با struct های C در اختیار داشتین؟ مگه توی c نمیشه برای یک struct فیلد تعریف کرد؟ مگه نمیشه متد تعریف کرد؟ این زبان ها فقط از
نظر سینتکس و روش استفاده، کاری کردن که شما با ساختار class همون کارها رو راحت تر و با انعطاف پذیری بالاتر انجام بدید. خوب اگه قضیه
اینه، ما نیاز به ساختار class نداریم، ما این راحتی و انعطاف پذیری رو با همون struct هایی که در C باهاشون کار میکردید به شما تقدیم
میکنیم. همه اینها به کنار، این که این زبان ذاتا Concurrent هست هم به کنار... اتفاقا همچین زبانی شیگرا تر از خیلی از زبانهای دیگهاس.
مساله ایی که هست، اینه که چیزی مثل Java یا ++C معرف برنامهنویسی شیگرا نیستن. لازم نیست همه شیگرایی رو درست عین اینها تعریف کنن.
خوب این یعنی شیگرایی با مدل Java و ++C بده؟ خیر. هر چیزی در جای مناسب استفاده بشه خوبه. هر چیزی به مقدار مناسب استفاده بشه خوبه.
اما برنامهنویس های این زبان ها ایده های شی گرایی رو تا جایی پیش میبرن که مغز آدم سوت میکشه. خیلی مواقع جوری کد نویسی میکنن که آدم
از خودش سوال میکنه آخه چرااااااااااا؟؟ این کاری که شما با پنج تا کلاس انجام دادی و کلی کد نوشتی (فقط به این دلیل که شیوهی پیاده سازی
شی گرا باشه)، میشد با دو تا تابع ساده انجامش داد!
اما اگه همین شی گرایی رو در اندازهی مناسب و جای مناسب به کار برد، خیای هم خوبه و باعت بهتر شدن ساختار برنامه میشه. مثلا یکی از
جاهایی که این مدل برنامهنویسی خیلی خوب توش جواب میده برنامه سازی GUI هست.
کجاها خوب جواب نمیده؟ یکی از این جاها موقع برنامهنویسی همروند هست. موقعی که اجزای برنامه باید واقعا مستقل از هم باشن، به طوری که حتی بتونن مستقل از هم اجرا بشن! (در صورت امکان اجرای موازی). در چنین شرایطی هست که زبانهایی مثل Go و Erlang و Clojure و
Haskell خیلی عالی عمل میکنن.
اون افرادی هم که اسمشون ذکر شده، در واقع منظورشون از شیگرایی چیزی هست که در Java و ++C میبینید. نه اینکه با این روش مخالف باشن،
اما صرفا به این صورت فکر نمیکنن که شیگرایی جوابیه برای تمام مشکلات. و اینکه میشه کارها رو خیلی ساده تر انجام داد و با پیچیدگیهای
شیگرایی هم درگیر نشد.
حداقل طراحی زبان طوری باشه که استایل کدنویسی رو تحمیل نکنه. به برنامه نویس اجازه بده در جایی که فکر میکنه شیگرایی مناسبه ازش استفاده کنه، و در جایی هم که فکر میکنه لازم نیست، مجبور به استفاده از این شیوه نباشه. وقتی از «استفاده» حرف میزنیم، منظورمون جنبهی
ظاهری یا سینتکس نیست، منظورمون استفاده از ایده های شیگرایی هست. همون مفاهیم شیگرایی که حتی در زبان های غیر شی گرا هم قابل استفاده
هستن.
------------
[1]:
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en