فرادرسبرنامه نویسی پروتکل محور (Protocol Oriented Programming) – به زبان ساده
برنامه نویسی پروتکل محور (Protocol Oriented Programming) در طی سال‌های اخیر در جامعه توسعه‌دهندگان سوئیفت (Swift) توجه زیادی را برانگیخته و به یک ترند تبدیل شده است. برخی افراد عاشق آن هستند و برخی دیگر از آن متنفرند؛ اما شاید از خود بپرسید برنامه‌نویسی پروتکل-محور واقعاً چیست؟ قرار است چه مسائلی را حل کند؟ و چه ارتباطی با مفهوم جاافتاده برنامه‌نویسی شیءگرا دارد؟
برنامه‌نویسی پروتکل-محور چیست؟
ابتدا باید اشاره کنیم که برنامه‌نویسی پروتکل محور، رقیب یا جایگزینی برای برنامه‌نویسی شیءگرا محسوب نمی‌شود. این رویکرد برنامه‌نویسی در واقع روشی برای تفکر در مورد یک مجموعه مسائل خاص است که به ایجاد یک کد انعطاف‌پذیر، قابل نگهداری و با خوانایی آسان کمک می‌کند. برنامه‌نویسی پروتکل–محور را بیشتر می‌توان یک مکمل برای رویکرد شیءگرایی تصور کرد. در واقع برنامه‌نویسی شیءگرا هم اینک شامل چندین مورد از ایده‌های اصلی برنامه‌نویسی پروتکل-محور است.
کار خود را با بررسی روش کمک پروتکل‌ها (یا چنان که در اغلب زبان‌های دیگر برنامه‌نویسی نامیده می‌شوند، اینترفیس‌ها) به کپسوله‌سازی و پنهان‌سازی اطلاعات شروع می‌کنیم. به مثال زیر از یک کلاس Car و کلاس Carrieer نگاه کنید.
به متد آخر در کلاس Carrier نگاه کنید. شاید این متد به نظرتان عجیب بیاید. یک Carrier نباید بتواند قفل خودروهایی که آن را حمل می‌کنند، باز کند. این عارضه جانبی اطلاع داشتن کلاس Carrier از آن چه حمل می‌کند و در نتیجه کسب دسترسی به متدهای عمومی در این اشیا است. ما می‌توانیم یک سوپرکلاس Vehicle را روی Car پیاده‌سازی کنیم و منطق قضیه را در آنجا قرار دهیم؛ اما اگر کلاس Car شامل متدهای دیگری نیز باشد باز با همین نوع مشکل مواجه خواهیم شد.
اینک به راه‌حل پروتکل-محور برای این مسئله را بررسی می‌کنیم. کار خود را با تقسیم کلاس‌هایمان به کلاس‌های کوچک‌تر آغاز می‌کنیم و آن‌ها را درون پروتکل‌هایی قرار می‌دهیم که خصوصیت و متدهایی که مناسب هستند را گرد هم خواهند آورد. در این راه‌حل خاص می‌توانیم کارکرد موردنظر را به سه پروتکل متفاوت به نام‌های Moveable ،Lockable و Loadable افراز کنیم:
به نظر می‌رسد این راه‌حل چاره مشکل ما است. بدین ترتیب ما همه خصوصیات و متدهایی که باید در دسترس عمومی باشند را فاکتور گرفته‌ایم و آن‌ها را به پروتکل‌هایی تبدیل کرده‌ایم که کارکرد موردنظر را به طور کاملاً مستقلی مدیریت می‌کنند. دقت کنید که هر دوی Moveable.position و Lockable.isLocked خصوصیات فقط-خواندنی هستند. دلیل انتخاب این طراحی از سوی ما این بوده است که این خصوصیات ممکن است برای وهله‌های دیگر نیز جذاب باشند؛ اما تنها خود شیء می‌تواند آن‌ها را دستکاری کند. همچنین می‌توانید در مورد روش دستکاری آن‌ها از سوی دیگران در پیاده‌سازی متدها تصمیم بگیرید. ما قصد داریم پیاده‌سازی این راه‌حل را از طریق تبدیل آن‌ها به خصوصیات محاسبه شده و اعلان کردن یک ذخیره‌سازی پشتیبانی برای آن‌ها پیاده‌سازی کنیم.
اکنون که کار تعیین کارکردها در پروتکل‌ها پایان یافته است، می‌توانیم کلاس‌های خود را طوری بازسازی کنیم که با پروتکل‌های مناسب تطبیق داشته باشند و همه چیزهایی را که قرار نیست از سمت بیرون در دسترس باشند، پنهان کنیم.
دقت کنید که وقتی اجازه می‌دهیم Carrier با اشیایی که پروتکل Moveable را پیاده‌سازی می‌کنند، سر و کار داشته باشد، باعث می‌شویم دسترسی آن به همه متدها و خصوصیاتی که به جابه‌جایی اشیا مربوط نیستند را از دست بدهد. آن چه که باعث شده این رویکرد مفیدتر باشد، آن است که موجب سهولت قابلیت کد ما شده است. بدین ترتیب carrier ما دیگر نمی‌داند که دقیقاً چه چیزی را جا به جا می‌کند و از این رو تا زمانی که اجازه می‌دهیم کلاس‌های جدید، پروتکل Moveable را پیاده‌سازی کنند، می‌توانیم اقدام به حمل و نقل خودرو، قایق، اثاثیه و تقریباً هر چیزی که می‌توان حمل کرد بپردازیم و همه این کارها بدون نیاز به تغییر دادن حتی یک خط کد در کلاس Carrier ممکن است.
همچنین به خاطر داشته باشید که struct-ها و Bool-ها در واقع انواع مقدار هستند. «خصوصیات محاسبه شده» ما می‌توانند متغیر ذخیره‌سازی پشتیبانی را به طور مستقیم بازگشت دهند، زیرا در واقع «نوع مقدار» (Value Type) هر بار که به جایی ارسال می‌شود، کپی می‌شود، یعنی ما هرگز هیچ مشکل نام مستعار (alias) با موقعیت‌های خود نخواهیم داشت.
مزیت‌های دیگر رویکرد پروتکل-محور
پروتکل‌ها صرفاً به خاطر پنهان‌سازی اطلاعات نیستند. در مثال دوم که در ادامه ارائه می‌کنیم، نشان خواهیم داد که پروتکل‌ها چگونه همراه با ژنریک (Generic) ها، موجب می‌شوند برنامه‌ها انعطاف‌پذیری بیشتری داشته باشند و همچنین مقدار کدی که باید نوشته شود را کاهش می‌دهند. به کد زیر نگاه کنید:
با این که این مثال چندان عملی به نظر نمی‌رسد؛ اما نکته قضیه را به خوبی نشان می‌دهد. در این کد می‌بینیم که متد یک عمل جمع ساده را اجرا کرده و نتیجه را بازگشت می‌دهد و هیچ چیز نادرستی در این مسئله وجود ندارد.
با این وجود، زمانی که دقیق‌تر نگاه می‌کنیم متوجه می‌شویم که در این روش باید کدهای بسیار زیادی بنویسیم تا بتوانیم همه انواع اعداد مختلفی که ممکن است با هم جمع شوند را پوشش دهیم. در این رویکرد نوع Float، Double و انواع دیگر، هر کدام به یک متد خاص نیاز دارند. ما می‌خواهیم یک تابع منفرد بنویسیم که چندین نوع مختلف از اعداد را بپذیرد و یک پاسخ صحیح بازگشت دهد. همچنین می‌خواهیم قیدهای بیشتری را در مورد انواع داده‌هایی که می‌تواند ارائه شوند تعریف کنیم. برای مثال معقول نیست که بخواهیم دو رشته را با هم جمع بزنیم. بدین منظور تعریف متد فوق را به صورت زیر اصلاح می‌کنیم:
اینک ما تابعی داریم که از پروتکل به عنوان یک «قید ژنریک» (Generic Constraint) استفاده می‌کند. بدین ترتیب می‌توانیم هر نوع عدد را با یک متد جمع بکنیم. تنها شرط ما این است که مقدارهای ورودی باید پروتکل Numeric را پیاده‌سازی کنند و از این طریق امکان اجرای عملیات حسابی روی آن را می‌یابیم. امیدواریم این مقاله بینش‌های جدید در مورد روش استفاده از برنامه‌نویسی پروتکل-محور در پروژه‌هایتان در اختیار شما قرار داده باشد.
اگر این مطلب برای شما مفید بوده است، آموزش‌های زیر نیز به شما پیشنهاد می‌شوند:
- مجموعه آموزش‌های برنامه‌نویسی
- آموزش زبان Swift (سوئیفت) برای برنامه نویسی iOS
- مجموعه آموزش‌های دروس مهندسی کامپیوتر
- آموزش آرایه در برنامه نویسی Swift (سوئیفت)
- پوش نوتیفیکیشن (Push Notification) در iOS با استفاده از Swift — به زبان ساده
- آرایه ها در زبان برنامه نویسی سوئیفت (Swift) — به زبان ساده
==
