این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.
اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.
قسمت دوم - OOP به جای چیز های درست به کار میرود
قسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!
اسب تروجان یا تروآ یک مجسمه چوبی تو خالی است که یونانی های باستان برای فریب دشمن از استفاده کرده اند. (ویکی پدیا)
به ما گفته شده است كه Encapsulation یكی از بزرگترین مزایای OOP است. قرار بود از وضعیت داخلی شی در برابر دسترسی خارجی محافظت کند. با این وجود یک مشکل کوچک وجود دارد. کار نمی کند.
محصور سازی-Encapsulation اسب تروجان OOP است. ایده انتشار وضعیت تغییر پذیر را با امن نشان دادن ان می فروشد.محصور سازی اجازه می دهد(و حتی تشویق میکند) کد ناامن در کد ما مخفیانه زندگی کند و باعث میشود کد ما از درون بپوسد.
به ما گفته شده است كه وضعیت عمومی ریشه همه شرها است. باید به هر قیمتی از ان جلوگیری کرد. آنچه که هرگز به ما گفته نشده این است که در حقیقت, encapsulation خودش یک وضعیت عمومی است.
برای کارآمدتر کردن کد ، اشیاء نه با مقدار خود بلکه با ارجاع-reference به آنها منتقل می شوند. اینجاست که "تزریق وابستگی-dependency injection" ضایع میشود.
بگذارید توضیح بدهم. هر وقت یک شیء را در OOP ایجاد می کنیم ، به وابستگی آن به سازنده-constructor اشاره می کنیم. سازنده ها هم وضعیت درونی خود را دارند. این شیء تازه ایجاد شده با خوشحالی منابع خود را به ان وابستگی(constructor), وابسته میکند و خوشحال است که به هر شکلی که بخواهد میتواند وضعیت داخلی سازنده را اصلاح کند. و همچنین این ارجاع را به موارد دیگری که ممکن است از ان استفاده کند منتقل میکند.
این یک نمودار پیچیده از اشیاء مشترک ایجاد می کند که در آخر وضعیت یکدیگر را تغییر میدهند. این به نوبه خود ، باعث ایجاد مشکلات عظیمی می شود زیرا نمی توان دید که چه عواملی باعث تغییر وضعیت برنامه شده است. ممکن است روزها در تلاش برای دیباگ کردن چنین تغییر وضعیت هایی تلف شود. اگر خوش شانس باشید و با همروندی-concurrency سر و کار نداشته باشید(بعدا در این مورد بیشتر حرف میزنم).
متد ها و ویژگی ها که امکان دسترسی به یک فیلد را به ما میدهند بهتر از تغییر مستقیم ان فیلد نیستند.فرقی نمی کند وضعیت یک شی با استفاده از یک فیلد خاص یا متد تغییر کند - نتیجه همان است: تغییر وضعیت.
برخی افراد می گویند OOP سعی می کند دنیای واقعی را شبیه سازی کند. این درست نیست - OOP هیچ ارتباطی با دنیای واقعی ندارد. تلاش برای مدل سازی برنامه ها با استفاده از اشیاء ، یکی از بزرگترین اشتباهات OOP است.
برنامه نویسی شی گرا تلاش می کند تا همه چیز را به عنوان سلسله مراتب اشیاء مدل سازی کند. متأسفانه ، در دنیای واقعی اشیا اینطور کار نمیکنند. اشیاء در دنیای واقعی با استفاده از پیام ها با یکدیگر در تعامل هستند اما اکثراً مستقل از یکدیگر هستند.
وراثت در OOP از دنیای واقعی الگوبرداری نمیکند. شیء پدر در دنیای واقعی قادر به تغییر رفتارشی فرزند در زمان اجرا نیست. حتی اگر شما DNA خود را از والدین خود به ارث ببرید ، آنها قادر به تغییر در DNA شما مطابق میل خود نیستند. شما "رفتارها" را از والدین به ارث نمی برید ، شما رفتارهای خودتان را توسعه می دهید. و شما قادر به "غلبه-override" بر رفتارهای والدین خود نیستید.
آیا تکه کاغذی که روی ان می نویسید متد "نوشتن" دارد؟ نه! شما یک کاغذ خالی دارید، یک قلم بر میدارید و متنی را می نویسید. شما به عنوان یک فرد متد "نوشتن" ندارید -- شما تصمیم می گیرید که متن را بر اساس رویدادهای خارجی یا افکار داخلی خود بنویسید.
این داستان لعنتی همچنان ادامه دارد...
