این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.
اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.
قسمت دوم - OOP به جای چیز های درست به کار میرود
قسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!
قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!
refactoring یکی از قسمت های مهم کار های روزانه برنامه نویسان است. از قضا ، کد OOP به سختی قابل ریفکتور است. refactoring قرار بود پیچیدگی را کمتر و کد را قابل اعتماد تر کند. در مقابل ، کد OOP ریفکتور شده بطور قابل توجهی پیچیده تر می شود - برای قابل تست کردن کد ، باید از تزریق وابستگی استفاده کنیم و واسط-interface ای برای کلاس ریفکتور شده ایجاد کنیم. حتی ، ریفکتور کردن کد OOP بدون ابزار اختصاصی مانند Resharper بسیار سخت است.
این کد ها را داریم:
قبل از ریفکتور کردن:
بعد از ریفکتور کردن:
در مثال ساده بالا ، تعداد خطوط فقط برای استخراج یک متد بیش از دو برابر شده است. چرا ریفکتور کردن پیچیدگی بیشتری ایجاد می کند ، در حالی که کد در درجه اول به منظور کاهش پیچیدگی ریفکتور میشود ؟
این مورد را با یک ریفکتور مشابه در کد غیر OOP در JavaScript مقایسه کنید:
قبل از ریفکتور:
بعد از ریفکتور:
کد به معنای واقعی کلمه یکسان باقی مانده است - ما فقط متد isValidInput را به فایلی دیگر منتقل کردیم و برای وارد کردن آن متد یک خط اضافه کردیم. ما همچنین به منظور قابلیت تست _isValidInput به امضای تابع اضافه کردیم.
این یک مثال ساده است ، اما در عمل پیچیدگی بصورت نمایی با بزرگتر شدن کد بیشتر می شود.
و این همه چیز نیست. ریفکتور کردن کد OOP بسیار خطرناک است. نمودارهای وابستگی پیچیده و وضعیت های پراکنده در سراسر کد OOP ، مغز انسان را قادر نمی سازد که همه مسائل بالقوه را در نظر بگیرد.
وقتی چیزی کار نمیکند چه کار میکنیم؟ این ساده است ، ما فقط دو گزینه داریم - آن را دور بیندازید یا سعی کنید آن را اصلاح کنید. OOP چیزی است که به راحتی قابل دور ریختن نیست ، میلیون ها توسعه دهنده در OOP آموزش می بینند. و میلیون ها سازمان در سراسر جهان از OOP استفاده می کنند.
احتمالاً اکنون می بینید که OOP واقعاً کار نمی کند ، کد ما را پیچیده و غیر قابل اعتماد می کند. و شما تنها نیستید! مردم چندین دهه است که تلاش می کنند تا مشکلات موجود در کد OOP را حل کنند ، سخت فکر می کنند.که نتیجه آن تولید بی شمار الگو طراحی شده است.
برنامه نویسی شی گرا مجموعه ای از دستورالعمل ها را ارائه می دهد که از نظر تئوری باید به توسعه دهندگان اجازه دهد سیستم های بزرگتر و بزرگتر را بصورت تدریجی بسازند: اصل SOLID ، تزریق وابستگی ، الگوهای طراحی و سایر موارد.
متأسفانه الگوهای طراحی چیزی جز چسب زخم نیستند. آنها فقط برای رفع کاستی های OOP وجود دارند. تعداد بی شمار کتاب در این زمینه نوشته شده است. آنها خیلی بد نیستند ، درصورتی که مسئولیت ورود پیچیدگی عظیم به کد های ما را برعهده نگرفته باشند.
در حقیقت ، نوشتن کد شیء گرا و خوب ، غیرممکن است. در یک طرف ماجرا ، یک کد OOP داریم که نا سازگار است و به نظر نمی رسد که مطابق استاندارد باشد. در طرف دیگر ماجرا ، ما یک برجی از کدهای بیش از حد مهندسی و یک دسته از انتزاعات نادرست داریمک که یکی در بالای دیگری ساخته شده است. الگوهای طراحی در ساخت چنین برج هایی از انتزاعات بسیار مفید هستند.
به زودی ، اضافه کردن قابلیت های جدید و حتی حس کردن همه پیچیدگی ها ، سخت تر و سخت تر می شود. کد مملو از مواردی مانند SimpleBeanFactoryAwareAspectInstanceFective ، AbstractInterceptorDrivenBeanDefinitionDecorator ، TransactionAwarePersistenceManagerFactoryProxyorRequestProcessorFactoryFective خواهد بود.
با تلاش برای فهم برج انتزاعات که خود توسعه دهندگان ایجاد کرده اند ، نیروس مغز گرانبها را هدر می دهیم. عدم وجود ساختار در بسیاری موارد بهتر از داشتن ساختار بد (اگر از من بپرسید) است.
این داستان در قسمت بعد به پایان خواهد رسید...
