برنامه نویسی شی گرا: فاجعه میلیارد دلاری -- قسمت چهارم

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