این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.
اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.
قسمت دوم - OOP به جای چیز های درست به کار میرود
قسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!
قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!
قسمت ششم - چسب زخم الگو های طراحی
چهار ستون OOP عبارت اند از : انتزاع-Abstraction و وراثت و محصور سازی-Encapsulation و چند ریختی-Polymorphism.
بیایید یکی یکی ببینیم واقعاً چه هستند
من فکر می کنم عدم قابلیت استفاده مجدد در زبانهای شی گرا و جود دارد، نه در زبانهای فانکشنال. مشکل زبانهای شی گرا این است که آنها کلی محیط ضمنی را با خود حمل میکنند. شما یک موز می خواستید اما آنچه شما گرفتید یک گوریل موز و کل جنگل بود. ---- Joe Armstrong خالق ارلانگ
وراثت OOP هیچ ارتباطی با دنیای واقعی ندارد. وراثت ، در حقیقت ، یک روش پایین دستی برای دستیابی به قابلیت استفاده مجدد از کد است. برخی از زبانهای برنامه نویسی مدرن به طور کلی از وراثت پشتیبانی نمیکنند.
وراثت چند مشکل دارد:
چند ریختی عالی است ، به ما این امکان را می دهد که رفتار برنامه را در زمان اجرا تغییر دهیم. با این حال ، این یک مفهوم بسیار مقدماتی در برنامه نویسی است. من نمی دانم که چرا OOP اینقدر به چند ریختی توجه می کند. چند ریختی OOP کار را انجام می دهد اما بار دیگر منجر به عمل دستکاری ذهنی می شود(در قسمت های قبل توضیح داده شده). این امر باعث می شود كه كد به طور قابل توجهی پیچیده تر شود و استدلال در مورد متد واقعی كه مورد استفاده قرار می گیرد واقعاً سخت می شود.
از طرف دیگر برنامه نویسی functional به ما این امکان را می دهد که به شکلی ظریف تر به همان چند ریختی دست یابیم ... به سادگی با ک استفاده از متدی که رفتار دلخواه ما در زمان اجرا را مشخص میکند. چه چیزی می تواند ساده تر از این باشد؟ نیازی به تعریف دسته ای از متد مجازی و اضافی بارگذاری شده در چندین فایل (و واسط) نیست.
همانطور که قبلاً بحث کردیم ، محصور کردن اسب تروجان OOP است. این در واقع یک وضعیت قابل تغییر عمومی(جهانی- global) قابل تغییر است و باعث می شود کد ناامن به نظر بی خطر برسد. کد ناامن ستونی است که برنامه نویسان OOP در کار روزانه خود به آن تکیه میکنند ...
انتزاع در OOP تلاش می کند با پنهان کردن جزئیات غیرضروری از برنامه نویس ، با پیچیدگی ها مقابله کند. از لحاظ تئوریک ، این امکان را برای توسعه دهنده فراهم می کند که بدون نیاز به فکر کردن در مورد پیچیدگی پنهان شده ، کد را تحلیل کند.
من نمی دانم چه بگویم ... یک کلمه جالب برای یک مفهوم ساده. در زبانهای رویه ای / functional ما می توانیم به سادگی جزئیات اجرا (همون پیچیدگی هایی که باید مخفی شود) را در یک فایل همسایه مخفی کنیم. نیازی نیست که این عمل پایه ای را "انتزاع" بنامیم.
پاسخ ساده است ، نژاد بیگانه ای از خزندگان با NSA (و روسها) توطئه كرده اند تا ما برنامه نویسان را تا حد مرگ شکنجه کنند...
اما به طور جدی ، جاوا احتمالاً پاسخ مورد نظراست.
جاوا نگران کننده ترین چیزی است که از زمان MS-DOS (ویکی پدیا)برای کامپیوتر اتفاق افتاده است. --- الن کی - خالق OOP
هنگامی که اولین بار در سال 1995 معرفی شد ، جاوا در مقایسه با گزینه های دیگر یک زبان برنامه نویسی بسیار ساده بود . در آن زمان ، موانع زیادی برای ورود به نوشتن برنامه های دسک تاپ بود. توسعه برنامه های دسک تاپ شامل نوشتن API های سطح پایین win32 در C است ، و توسعه دهندگان نیز مجبور بودند که خود را با مدیریت حافظه دستی نگران کنند. جایگزین دیگر ویژوال بیسیک بود ، اما احتمالاً بسیاری نمی خواستند خود را در اکوسیستم مایکروسافت قفل کنند.
هنگامی که جاوا معرفی شد ، برای بسیاری از برنامه نویسان واضح بود چونکه رایگان بود ، و می توانست در تمام سیستم عامل ها مورد استفاده قرار گیرد. مواردی مانند جمع آوری زباله های داخلی ، API هایی با نام دوستانه (در مقایسه با API های رمزنگاری win32) ، مکان های نام مناسب و سینتکس آشنای C مانند جاوا را قابل دسترسی تر می کند.
برنامه نویسی GUI نیز رایج تر شد و به نظر می رسید که کامپوننت های مختلف UI به خوبی با کلاس ها سازگار شده اند. تکمیل خودکار متد در IDE همچنین باعث شد تا مردم ادعا کنند که API های OOP ساده تر هستند.
شاید جاوا اینقدر بد نمی بود اگر برنامه نویسان را به استفاده از OOP مجبور نمیکرد. همه چیز در مورد جاوا بسیار خوب به نظر می رسید. جمع آوری زباله ، قابلیت حمل و نقل ، ویژگی های دست زدن به استثناء ، که سایر زبان های برنامه نویسی اصلی فاقد آن بودند ، در سال 1995 واقعاً عالی بودند ،
در ابتدا ، مایکروسافت به شدت به جاوا تکیه کرده بود. هنگامی که همه چیز بدتر شد (و پس از یک نزاع حقوقی طولانی با Sun Microsystems بر سر صدور مجوز جاوا) ، مایکروسافت تصمیم گرفت روی نسخه ای شخصی از جاوا سرمایه گذاری کند. این زمانی است که C # 1.0 به دنیا آمد. C # به عنوان یک زبان همیشه به عنوان "جاوا بهتر" تصور می شد. با این حال ، یک مشکل بزرگ وجود دارد - این همان زبان OOP با همان نقص ها بود ، که در زیر یک سینتکس کمی بهبود یافته پنهان شده بودند.
مایکروسافت سرمایه گذاری زیادی در اکوسیستم .NET خود انجام داده است ، که شامل ابزارهای توسعه دهنده خوبی نیز می باشد. سالهاست که ویژوال استودیو احتمالاً یکی از بهترین IDE های موجود بوده است. این به نوبه خود منجر به تصویب گسترده چارچوب .NET ، به ویژه در شرکت شده است.
اخیراً مایکروسافت با هل دادن TypeScript خود سرمایه گذاری زیادی در اکوسیستم مرورگر انجام داده است. TypeScript بسیار عالی است زیرا می تواند جاوا اسکریپت خالص را کامپایل کند و مواردی مانند بررسی نوع استاتیک را اضافه می کند. انچه در ان جالب نیست این است که از پشتیبانی مناسب برای ایجاد برنامه های فانکشنال برخوردار نیست - هیچ ساختار داده غیرقابل تغییری ساخته شده نشده ، ترکیب متد وجود ندارد و عدم تطبیق الگوی مناسب. TypeScript اول OOP است ، و بیشتر C # برای مرورگر ها است. Anders Hejlsberg حتی مسئول طراحی هر دو C # و TypeScript بود.
از سوی دیگر ، زبانهای functional هرگز توسط کسی به اندازه مایکروسافت پشتیبانی نشده اند. F # حساب حساب نمیشود زیرا سرمایه گذاری ناچیزی پشت ان بود. توسعه زبانهای functional بیشتر جامعه محور است. این احتمالاً تفاوت محبوبیت بین زبانهای OOP و FP را توضیح می دهد.
اکنون می دانیم که OOP تجربه ای است که شکست خورده است. وقت حرکت است. زمان آن رسیده است که ما به عنوان یک جامعه بپذیریم که این ایده ما را ناکام کرده است و باید از آن ترک کنیم. --- Lawrence Krubner
چرا ما از چیزی استفاده می کنیم که اساساً یک راه کم اهمیت برای سازماندهی برنامه ها است؟ آیا این جاهلیت آشکار است؟ من شک دارم ، افرادی که در مهندسی نرم افزار کار می کنند احمق نیستند. آیا با استفاده از اصطلاحات فانتزی OOP مانند "الگوهای طراحی" ، "انتزاع" ، "محصور سازی" ، "چند ریختی" و "تفکیک واسط-interface segregation" ، میخواهیم بین همسالانمان "هوشمند" به نظر برسیم؟ احتمالا نه.
من فکر می‌کنم که استفاده از چیزی که چندین دهه است از آن استفاده کرده‌ایم، ادامه پیدا کند. اکثر مردم هرگز واقعا یک برنامه‌نویسی functional را امتحان نکرده اند. آن‌هایی که مثل من (مثل خودم) امتحان کرده اند هرگز نمی‌توانند به نوشتن کد OOP برگردند.
هنری فورد یک جمله معروف دارد: "اگر من از مردم میپرسیدم چه چیزی میخواهند ، آنها سریع می گفتند اسب". در دنیای نرم افزار ، بیشتر افراد احتمالاً "زبان OOP بهتر" می خواهند. مردم به راحتی می توانند مشکلی را که دارند (بدست اوردن کد سازماندهی شده و ساده تر) توصیف کنند ، اما بهترین راه حل نیست.
هشدار اسپویل: برنامه نویسی functional.
اگر اصطلاحاتی از قبیل functor ها و monad ها شما را کمی ناراحت می کند ، پس تنها نیستید! برنامه نویسی کاربردی چندان ترسناک نبود اگر نام های شهودی بیشتری به برخی از مفاهیم آن داده شده بود. Functor؟ خیلی ساده,چیزی است که با یک متد میشود ان را توصیف کرد ,مثلا list.map. موناد-Monad؟ به سادگی محاسباتی که می توان زنجیره ای کرد!
امتحان کردن برنامه نویسی functional شما را به یک توسعه دهنده بهتر تبدیل می کند. سرانجام به جای این که بیشتر وقت خود را صرف فکر کردن در مورد انتزاع و الگوهای طراحی کنید ، زمان را صرف نوشتن کد واقعی برای حل مشکلات در دنیای واقعی را خواهید کرد.
ممکن است شما متوجه این موضوع نشوید ، اما در حال حاضر یک برنامه نویس functional هستید. آیا در کار روزانه خود از توابع استفاده می کنید؟ آره؟ سپس شما در حال حاضر یک برنامه نویس functional هستید! فقط باید یاد بگیرید که چگونه می توانید از این توابع بهترین استفاده را ببرید.
دو زبان functional عالی با منحنی یادگیری بسیار ملایم Elixir و Elm هستند. آنها به توسعه دهنده روی چیزی که مهم تر است تمرکز کنند -- نوشتن نرم افزار قابل اعتماد در حالی که تمام پیچیدگی هایی را که زبانهای کاربردی سنتی تر دارند از بین ببرد.
گزینه های دیگر چیست؟ آیا شرکت شما قبلاً از C # استفاده می کرد؟ سعی کنید F # را امتحان کنید - یک زبان کاربردی شگفت انگیز است ، و قابلیت همکاری عالی با کد NET موجود را فراهم می کند. استفاده از جاوا؟ سپس استفاده از Scala یا Clojure هر دو گزینه خوب هستند. از JavaScript استفاده می کنید؟ با راهنمایی و پوشش صحیح ، جاوا اسکریپت می تواند یک زبان functional خوب باشد.
من انتظار نوعی عکس العمل از مدافعان OOP دارم. آنها خواهند گفت كه این مقاله مملو از غلط است. برخی حتی ممکن است شروع به نام بردن اسم کنند. آنها حتی ممکن است من را یک توسعه دهنده "جوان" بنامند که هیچ تجربه OOP در دنیای واقعی ندارد. ممکن است برخی بگویند فرضیات من اشتباه است و مثال های آن بلا استفاده است.
آنها حق نظر خود را دارند. با این حال ، استدلال های آنها در دفاع از OOP معمولاً بسیار ضعیف است. طعنه آمیز است که احتمالاً اکثر آنها هرگز واقعا با زبان functional برنامه نویسی نکرده اند. اگر کسی که واقعاً هر دو را امتحان نکرده باشد ، چگونه می تواند بین دو چیز مقایسه کند؟ چنین مقایسه هایی مفید نیستند.
قانون Demeter خیلی هم مفید نیست - هیچ کاری برای پرداختن به مسئله عدم قطعیت نمی کند ، وضعیت تغییر پذیر هنوز هم وضعیت تغییر پذیر است ، مهم نیست که چگونه به آن حالت دسترسی پیدا کرده یا تغییر پیدا کند. a.total () خیلی بهتر از a.getB().getC().total()نیست؟.
قانون Domain-Driven Design؟ این یک روش طراحی مفید است ، و کمی به کاهش پیچیدگی کمک می کند. با این حال ، هنوز هیچ کاری برای پرداختن به مسئله اساسی وضعیت مشترک قابل تغییر پذیر نمی کند.
من اغلب می شنوم که مردم می گویند OOP فقط یکی دیگر از ابزارهای جعبه ابزار است. بله ، به همان اندازه یک ابزار در جعبه ابزار است زیرا اسب ها و ماشین ها هر دو وسیله حمل و نقل هستند ... از اینها که بگذریم ، همه آنها به همان هدف خدمت می کنند ، درست است؟ چرا وقتی می توانیم سوار اسب های قدیمی خوب شویم ، از اتومبیل استفاده می کنیم؟
این در واقع چیزی را به من یادآوری می کند. در آغاز قرن بیستم ، اتومبیل ها شروع به جایگزینی اسب ها کردند. در سال 1900 در نیویورک تنها چند اتومبیل در جاده ها وجود داشت ، مردم از اسب ها برای حمل و نقل استفاده می کردند. در سال 1917 ، دیگر اسب در جاده ها باقی نماند. صنعت عظیمی حول حمل و نقل با حمل اسب قرار داشت. مشاغل زیادی پیرامون مواردی مانند تمیز کردن کود ایجاد شده بود.
و مردم در برابر تغییر مقاومت کردند. آنها اتومبیل ها را یکی دیگر از "مد" خواندند که در نهایت می گذرد.هر چه باشد، اسب ها قرن ها در اینجا بوده اند! برخی حتی از دولت خواستند كه مداخله كند.
یعنی چه؟ صنعت نرم افزار تقریبا OOP محور است. میلیون ها نفر در OOP آموزش دیده اند ، و میلیون ها شرکت در کد خود از OOP استفاده می کنند. البته آنها سعی خواهند کرد هر چیزی را که تهدید کننده نان و کره آنها است ، بی اعتبار کنند! این فقط عقل سلیم است.
ما به وضوح می بینیم که تاریخ در حال تکرار است - در قرن بیستم این اتومبیل ها در مقابل اسب ها بودند ، در قرن بیست و یکم این برنامه نویسی شیء گرا در مقابل functional است.
بالاخره این مقاله تمام شد. تمام تلاشم رو کردم که ترجمه خوبی اراعه بدم . اما حتما اشکالاتی وجود دارد که امیدوارم بهم بگید تا بتونم اونو اصلاح و ترجمه تر و تمیزی رو تحویل ایندگان بدم.
