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

این پست ترجمه بخشی از مقاله "Object-Oriented Programming — The Trillion Dollar Disaster" از Medium است. مقاله اصلی خیلی طولانی بود . به همین خاطر مجبور شدم ان را به چند بخش تقسیم کنم.

اگر قسمت های قبل را نخوانده اید , خواندن این بخش را متوقف کنید و از قسمت اول بخوانید تا اصل ماجرا را بفهمید.

قسمت اول - مقدمه

قسمت دوم - OOP به جای چیز های درست به کار میرود

قسمت سوم - من متاسفم که اصطلاح اشیا را ابداع کردم!

قسمت چهارم - OOP ربطی به دنیای واقعی ندارد!

قلمرو اشیا

اشیاء ,توابع و ساختار داده ها را در واحدهای غیر قابل تفکیک در کنار هم جمع میکنند. من فکر می کنم این یک خطای اساسی است زیرا توابع و ساختار داده ها کاملا به دنیا های متفاوتی تعلق دارند. --— Joe Armstrong خالق زبان ارلانگ

اشیاء هسته اصلی OOP هستند. یک محدودیت اساسی OOP این است که همه چیز را به اشیا سوق می دهد. و همه چیز را نباید بر پایه اشیا مدل سازی کرد. توابع نباید بر اساس اشیاء مدل شوند. چرا ما باید کلاسMultiplier (ضرب) را ایجاد کنیم وقتی همه آنچه که نیاز داریم یک تابع است که دو عدد را ضرب کند؟ به سادگی یک تابع Multiply داشته باشید ، بگذارید داده ها(data) داده و توابع توابع باشند!

در زبان های غیر OOP ، انجام کارهای مهم مانند ذخیره داده ها در یک فایل ساده است .

یک مثال واقعی, خواهش میکنم!

برگردیم به مثال نقاش(در قسمت سه) ، نقاش صاحب یک PaintingFactory (کارخانه نقاشی!)است. او یک BrushManager اختصاصی ، ColorManager ، یک CanvasManager و یک MonaLisaProvider را ایجاد کرده است. زامبی دوست خوب او از BrainConsumingStrategy استفاده می کند. این اشیاء به نوبه خود متد های زیر را تعریف می کنند: CreatPainting ، FindBrush ، PickColor ، CallMonaLisa و ConsumeBrainz.

البته ، این حماقت آشکار است ، و هرگز نمی توانست در دنیای واقعی اتفاق بیفتد. چقدر پیچیدگی غیر ضروری برای ترسیم یک نقاشی ایجاد شده است؟ وقتی توابع میتوانند مستقل از یک شی وجود داشته باشند , دیگر نیازی به ایجاد مفاهیم عجیب و غریب (کلاس ها)برای نگه داشتن متد ها نیست.

تست واحد - Unit Testing

تست خودکار بخش مهمی از فرآیند توسعه است و در جلوگیری از regressions فوق العاده کمک می کند (یعنی اشکالات موجود در کد موجود). تست واحد نقش مهمی در روند تست خودکار بازی می کند.

برخی ممکن است مخالف باشند ، اما تست واحد کد OOP بسیار سخت است. تست واحد فرضیه آزمایش جداگانه چیز ها را اراعه میکند و برای اینکه یک متد قابل تست باشد:

• به یک کلاس مجزا وابسته باشد.
• یک واسط(interface) برای کلاس ایجاد شده ساخته شده باشد.
• یک فیلد برای نگهداری کلاس جدید ایجاد شده باشد
• برای "تزریق وابستگی" از یک چارچوب برای تزریق وابستگی استفاده کنید.

چقدر باید پیچیدگی بیشتری ایجاد شود تا یک تکه کد قابل تست کردن باشد؟ چقدر زمان صرف شده است تا برخی از کدها قابل تست باشند؟

پ.ن: ، ما همچنین باید یک کلاس کامل را مقداردهی(instantiate) کنیم تا بتوانیم یک متد واحد را آزمایش کنیم.

به لطف OOP ، نوشتن تست برای کد موروثی(ویکی پدیا) حتی سخت تر است - تقریبا غیرممکن است. شرکتهای زیادی پیرامون مسئله آزمایش کد موروثی ایجاد شده اند.

کد اضافی - Boilerplate code

کد اضافی احتمالاً بزرگترین متخلف در رابطه با نسبت سیگنال به نویز است. کد اضافی "نویز" است که برای کامپایل برنامه لازم است. برای نوشتن کد اضافی وقت نیاز دارید و باعث می شود که کد به دلیل نویز اضافه شده ، خوانایی کمتری داشته باشد.

در حالی که "program to an interface, not to an implementation" روش پیشنهادی در OOP است ، هر چیزی نباید به یک واسط تبدیل شود. ما تنها باید به منظور قابلیت تست کردن از واسط ها در همه کد استفاده کنیم. ما همچنین احتمالاً باید از تزریق وابستگی استفاده کنیم ، که باعث پیچیدگی های غیر ضروری می شود.

تست کردن متد های خصوصی- private

بعضی ها می گویند که متد های خصوصی نباید تست شوند ... من تمایل ندارم که مخالف باشم ، تست واحد به یک دلیل "واحد" نامیده می شود - واحدهای کوچک کد را در انزوا آزمایش کنید. اما آزمایش متد های خصوصی در OOP تقریبا غیرممکن است. ما نباید فقط به خاطر تست پذیری ، متد های خصوصی را ایجاد کنیم.

برای دستیابی به قابلیت تست متدهای خصوصی ، معمولاً آنها باید روی یک شی جداگانه انجام شوند. این به نوبه خود ، پیچیدگی و کد اضافی تولید میکند.

این داستان حالا حالا ها ادامه دارد ...