VIP همه چیز درباره برنامه نویسی

[☾♔TALAYEH_A♔☽]

م کنترل نسخه) چیست؟
Version Control System یا به اختیار VCS (سیستم کنترل نسخه) چیست؟


یک برنامه‌نویس مبتدی تا زمانی که با چیزی تحت عنوان Version Control System (سیستم کنترل نسخه) آشنایی نداشته باشد، هرگز نخواهد توانست برچسب حرفه‌ای روی خود بزند! شرکت‌های نرم‌افزار تراز اول، برنامه‌نویسان باتجربه و به طور کلی حرفه‌ای‌ها در دنیای برنامه‌نویسی در پروسهٔ کاری خود از یکسری VCS استفاده می‌کنند و آنچه در این فصل قصد داریم بررسی کنیم، مقدمه‌ای بر این دست سیستم‌ها به همراه انواع آن‌ها و مزایای استفاده از چنین سیستم‌هایی است.

Version Control System که به اختصار VCS خوانده می‌شود عبارت است از سیستمی که به توسعه‌دهندگان نرم‌افزار کمک می‌کند تا علاوه بر امکان مشارکت روی پروژه‌های نرم‌افزاری، بتوانند به تاریخچه‌ای از کدهایی که قبلاً نوشته‌اند نیز دست پیدا کنند و به طور کلی اهداف استفاده از سیستم‌های ورژن کنترل (VCS) را می‌توان در موارد زیر خلاصه نمود:

- فراهم آوردن فرصتی برای توسعه‌دهندگان به منظور کار کردن به صورت هم‌زمان
- مجزاسازی نسخه‌های توسعه داده شدهٔ اختصاصی تک‌تک توسعه‌دهندگان
- نگهداری تاریخچه‌ای از هر نسخه از هر چیزی که به اشتراک گذاشته شود

به طور کلی، می‌توانیم سیستم ورژن کنترل را به عنوان یک دیتابیس در نظر بگیریم که به توسعه‌دهندگان این اجازه را خواهد داد تا در هر زمانی که تمایل داشته باشند، نسخه‌ای از نرم‌افزار مد نظر خود را در آن ذخیره سازند. حال در آینده زمانی که به یکسری Version (نسخه) قدیمی نگاهی می‌اندازیم، دقیقاً متوجه خواهیم شد که کدام بخش از نرم‌افزار دستخوش تغییر شده است. به طوری کلی، از جمله مزایای نرم‌افزارهای ورژن کنترلی مثل Git این است که محدود به زبان برنامه‌نویسی خاص و همچنین ویرایشگر کد خاصی نبوده و هر نوع سورس‌کدی که با هر نرم‌افزاری نوشته شده باشد را ساپورت می‌کنند (برای آشنایی بیشتر با گیت می‌توانید به مقالهٔ Version Control (ورژن کنترل) چیست و Git چگونه کار می‌کند؟ مراجعه نمایید.)

به خاطر داشته باشید
به غیر از برنامه‌نویسان و توسعه‌دهندگان، سایر کاربرانی که در حوزه‌های دیگری همچون طراحی، نویسندگی و ... کار می کنند نیز خواهند توانست از سیستم‌های ورژن کنترل استفاده نمایند.
پیش از این گفتیم که به غیر از دولوپرها، سایر کاربرانی همچون دیزاینرها و ... هم می‌توانند از چنین نرم‌افزارهایی استفاده کنند که برای کسب اطلاعات بیشتر می‌توانید به مقالات زیر مراجعه نمایید:

- Trunk: سرویس ورژن کنترل امن برای فایل‌های گرافیکی
- Simul: ورژن کنترلی مخصوص نرم‌افزار Microsoft Word

همچنین با دنبال کردن‌ تگ‌های #ورژن کنترل و #گیت در وبلاگ سکان آکادمی، می‌توانید به سایر مقالات مرتبط با این حوزه دست یابید.

 

[☾♔TALAYEH_A♔☽]

چرا می بایست از ورژن کنترل استفاده کنیم؟


برنامه نویسی یکی از حوزه هایی است که در آن کار گروهی به معنای واقعی کلمه نمود عینی دارد. به عبارت دیگر، برخی از پروژه های عظیم برنامه نویسی آنقدر گسترده هستند که یک برنامه نویس هرگز به تنهایی از عهده ی آن برنخواهد آمد. پس در چنین شرایطی نیاز است تا دو یا بیش از دو برنامه نویس روی پروژه ای واحد شروع به کار کنند.

در شرایط عادی، برنامه نویسان می‌توانند در یک شبکه ی داخلی، فولدری مثلاً تحت عنوان Project را اصطلاحاً Share کرده یا «به اشتراک گذاشته» و هر کسی بخشی از کار را دست گرفته و شروع به کدزنی کنند و همین جا است که مشکل شروع می شود!

فرض کنیم که یکی از اعضای تیم بهزاد نام دارد و دیگری محمد. بهزاد در حال کار کردن روی فایلی است تحت عنوان مثلاً cart-check-out.php که در چنین شرایطی می بایست به محمد بگوید که یک بار شروع به کار کردن روی این فایل نکند چرا که در این صورت، تغییراتی که بهزاد دارد روی فایل می‌دهد ممکن است از دست بروند.

حال فرض کنیم به غیر از بهزاد و محمد، چندین توسعه‌دهنده ی دیگر هم به تیم اضافه می‌شوند و اینجا است که عمق فاجعه هم دوچندان شده و امکان بروز خطا چندین برابر خواهد شد. در اینجا است که وجود یک نرم‌افزار ورژن کنترل شدیداً احساس می گردد. در چنین نرم افزاری، هر یک از اعضای تیم این امکان را خواهد داشت تا با فراغ بال در هر کجا و هر زمانی شروع به کار روی هر فایلی از پروژه که خواست بکند چرا که در نهایت، نرم‌افزار ورژن کنترل این امکان را به ما خواهد داد تا کلیه ی تغییرات را اصطلاحاً Merge یا «ادغام» کرده و کلیه ی توسعه دهندگان از تمامی تغییرات برخوردار خواهند شد.

علاوه بر این، در شرایطی که تیم های توسعه ی نرم‌افزار از ورژن کنترل استفاده نکنند، به دشواری خواهند توانست اقدام به Backup (بکاپ یا نسخه ی پشتیبان) گیری نرم‌افزار خود کنند. مهم‌ترین مسأله در اینجا، نامگذاری نسخه ها است تا در آینده بر آن اساس بتوان یک نسخه ی خاص را یافت. اگر فرض را هم بر این بگذاریم که بتوانیم به نسخه ی بکاپ مد نظر خود دست پیدا کنیم، حال چگونه می بایست متوجه شویم که در این نسخه ی مد نظر چه بخش‌هایی دستخوش تغییر شده اند.

تمامی نقاط ضعف فوق الذکر، ما را مجاب خواهد کرد که به سمت ورژن کنترل مهاجرت کنیم. در سیستم‌های ورژن کنترل، پروژه ی ما صرفاً یک نسخه بیشتر نخواهد داشت که نسخه ی نهایی است و سایر نسخه ها نیز به عنوان بکاپ در نظر گرفته خواهند شد که به سادگی قابل دسترسی هستند.

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

 

[☾♔TALAYEH_A♔☽]

انواع سیستم‌های ورژن کنترل


در این آموزش قصد داریم تا دو سیستم ورژن کنترل معروف که عبارتند از Subversion و Git را مقایسه کنیم. Subversion که به اختصار SVN نیز خوانده می شود یک سیستم کنترل نسخه ی اصطلاحاً Centralized یا «متمرکز» است. به عبارت دیگر، تمامی اعضای تیم توسعه ی نرم‌افزار روی یک نسخه ی واحد که روی سروری خاص قرار دارد کار می کنند. وقتی توسعه‌دهنده ای اقدام به دریافت یک نسخه از پروژه از روی سرور می کند، اس وی ان آخرین نسخه از پروژه را در اختیار وی قرار خواهد داد.

در سیستم ورژن کنترل Git که یک سیستم اصطلاحاً Distributed یا «نامتمرکز» است، شرایط تا حدودی متفاوت تر است. زمانی که یکی از توسعه دهندگان پروژه ای را از روی سرور اصطلاحاً Clone (کلون به معنی دریافت کردن) می کند، وی نسخه‌ای کامل و جامع از آنچه روی سرور قرار دارد را در دست خواهد گرفت که شامل تاریخچه ی تغییرات پروژه نیز می باشد.

ساختار Repository و URL
Repository (ریپازیتوری یا منبع) در سیستم ورژن کنترل اس وی ان از یکسری دایرکتوری هایی تشکیل شده است که آشنایی با آن‌ها خالی از لطف نیست. Trunk به دایرکتوری اصلی پروژه اطلاق می شود، Branch (برنچ یا شاخه)برای مشخص سازی نسخه های مختلف در نظر گرفته می‌شود و Tag هم به منظور برچسب زدن روی برخی نسخه های خاص مورد استفاده قرار می گیرد. برای دستیابی به این بخش‌های مختلف یک ریپازیتوری، از آدرس‌های URL به شکل زیر استفاده می شود:

svn+ssh://[email protected]/svn/trunk
ریپازیتوری های سیستم ورژن کنترل گیت صرفاً از یک فولدر تحت عنوان git. تشکیل شده‌اند که داخل فولدر اصلی یک پروژه قرار می گیرد. به منظور دستیابی به Branch ها یا Tag های مختلف یک پروژه، به جای آدرس URL می بایست از Command (کامند یا دستور) های گیت استفاده کنیم. یو آر ال یک پروژه در سیستم ورژن کنترل گیت به شکل زیر خواهد بود:

ssh://[email protected]/path/to/git-repo.git
برنچ
معنی لغوی Branch «شاخه» است و برای درک بهتر این موضوع، می‌توان پروژه ی اصلی را به مثابه ی یک درخت تلقی کرد که روی هر شاخه ی آن می‌توان هر چیزی که تمایل داشته باشیم ایجاد کرده و این در حالی است که هر شاخه مجزا از سایر شاخه ها می‌تواند مورد استفاده قرار گیرد. همان‌طور که قبلاً توضیح داده شد، در سیستم ورژن کنترل اس وی ان، دایرکتوری هایی که دارای معنای خاصی هستند -مثلا به زمان یا تغییرات خاصی اشاره می کنند- تحت عنوان برنچ شناخته می شوند. زمانی که یک برنچ جدید می سازیم، ما یک کپی از کل پروژه در یک فولدر جدید ساخته ایم.

در سیستم ورژن کنترل گیت، برنچ معنای متفاوتی نسبت به اس وی ان دارا است. در گیت، برنچ به بخش خاصی از یک نسخه اشاره می‌کند بنابراین، به هیچ وجه هیچ گونه کپی جدید از پروژه، دایرکتوری های جدید و فایل‌های جدیدی از روی پروژه ی اصلی ساخته نخواهد شد. در سیستم گیت، به محض ایجاد یک پروژه، یک برنچ هم به صورت پیش‌فرض تحت عنوان Master یا «اصلی» ایجاد می‌گردد و شما به عنوان یک توسعه دهنده، همواره روی یک برنچ در گیت کار می کنید. پروژه ای که روی آن کار می کنید، حاوی فایل‌هایی است که متعلق به برنچ فعال اصلی که اصطلاحاً Head نامیده می‌شود می‌باشند و کلیه ی نسخه ها و برنچ های دیگر در ریپازیتوری لوکال -سیستم خودتان- ذخیره خواهند شد.

آشنایی با مفهوم Commit در ورژن کنترل
زمانی که در سیستم اس وی ان چیزی را Commit (کامیت به معنی سپردن) می کنیم، شرایطی خاصی برقرارند که عبارتند از:

- شما صرفاً زمانی می‌توانید تغییری را کامیت کنید که به ریپازیتوری مرکزی متصل باشید و در حالت آفلاین چنین امکانی برای شما وجود نخواهد داشت.
- کامیت شما خیلی سریع به ریپازیتوری مرکزی منتقل خواهد شد.
- شماره ای از نزولی به صعوی به کامیت شما اختصاص خواهد یافت که به عنوان شناسه ی کامیت شما در نظر گرفته می شود.

کامیت کردن در گیت تا حدودی متفاوت است. برخی خصوصیات کامیت در گیت عبارتند از:
- برای کامیت کردن، شما اصلاً نیازی به آنلاین بودن و داشتن ارتباط با ریپازیتوری اصلی نخواهید داشت چرا که نسخه ی کامل و جامعی از پروژه روی سیستم لوکال شما قرار دارد. لذا کامیت ها در ریپازیتوری لوکال شما ثبت شده و صرفاً زمانی که خودتان تصمیم بگیرید، به ریپازیتوری اصلی یا آنلاین انتقال خواهند یافت.
- صرفاً به این خاطر که یک فایل تغییر کرده است بدان معنا نیست که فایل مد نظر به صورت خودکار می بایست در کامیت بعدی در نظر گرفته شود. خود توسعه‌دهنده می بایست تغییراتی که مد نظرش هستند را مشخص کند تا در کامیت در نظر گرفته شوند.
- از آنجا که کامیت ها در ریپازیتوری لوکال توسعه‌دهنده که آفلاین است اعمال می شوند، سیستم گیت قادر نخواهد بود تا مشخص کند مثلاً کامیت شماره 5 متعلق به کدام توسعه‌دهنده است. لذا شماره های نسخه های مختلف در گیت اصطلاحاً Hash یا «رمزنگاری» می‌شوند تا هر کامیت دارای یک شناسه منحصر به فرد باشد.

به اشتراک گذاری
در اس وی ان، پروژه ی شما زمانی که آن را کامیت می کنید به صورت خودکار به سرور مرکزی انتقال داده خواهد شد و کامیت کردن صرفاً زمانی امکان‌پذیر است که شما با سرور مرکزی ارتباط آنلاین داشته باشید اما در گیت هیچ چیزی به صورت خودکار به سرور اصلی سپرده نخواهد شد و این توسعه‌دهنده است که تصمیم می‌گیرد که برنچ با اعضای تیم به اشتراک گذاشته شود یا خیر!

علاوه بر این، به اشتراک گذاری پروژه کاملاً ایمن است، Conflict (کانفلیکت یا تداخل) صرفاً روی سیستم لوکال توسعه‌دهنده ایجاد می‌شود و هرگز اتفاق بدی برای پروژه ی قرار گرفته روی سرور نخواهد افتاد! همین مسأله منجر می‌گردد که برنامه نویسان مبتدی با خیال راحت کار کنند و هرگز نگران این نباشند که سهواً پروژه ای که روی ریپازیتوری اصلی قرار گرفته است را خراب کنند.

 

[☾♔TALAYEH_A♔☽]

تاریخچه ی سیستم ورژن کنترل گیت


هسته ی لینوکس -Linux Kernel- یک پروژه ی اپن سورس واقعا عظیم است و توسعه دهندگان زیادی از سراسر دنیا روی آن کار می کنند. در سال های اولیه ی شکل گیری لینوکس، بخش اعظمی از این پروژه در قالب فایل‌هایی که توسط برنامه نویسان مختلف توسعه داده می‌شد و در اختیار ادمین -یا ادمین های پروژه- قرار می‌گرفت و ایشان مسئول اعمال تغییرات مد نظر بودند تا این که تیم توسعه ی لینوکس در سال 2002 شروع به استفاده از یک سیستم ورژن کنترل تحت عنوان BitKeeper کرد.

در سال 2005 ارتباط مابین توسعه دهندگان هسته ی لینوکس و شرکتی که نرم‌افزار Bitkeeper را طراحی کرده بود رو به سردی گذاشت و همین مسأله منجر به این گشت تا جامعه ی توسعه دهندگان لینوکس -به خصوص خالق اصلی هسته ی لینوکس آقای لینوس تروالدز- تصمیم به این گرفتند تا بر اساس درس‌هایی که از نرم‌افزار قبلی گرفته بودند، سیستم ورژن کنترل اختصاصی خود را طراحی کنند.

از همان روز نخست، جامعه ی توسعه دهندگان لینوکس سرعت، سادگی، پشتیبانی قوی، امکان کار کردن از راه دور و همچنین قابلیت پشتیبانی از پروژه های بزرگ را مد نظر داشتند. نتیجه این شد که سیستم ورژن کنترل GIT که یک ابزار اپن سورس و رایگان است در سال 2005 متولد شد که بخش اعظمی از آن با زبان C نوشته شده است. در حال حاضر، این سیستم به عنوان معروف ترین و محبوب ترین سیستم ورژن کنترل دنیا محسوب می گردد که شرکت های بزرگی همچون یاهو، توییتر، گوگل، آمازون، مایکروسافت و اپل از آن استفاده می کنند.

 

[☾♔TALAYEH_A♔☽]

چرا سیستم ورژن کنترل گیت؟


اگرچه در حال حاضر سیستم‌های ورژن کنترل بسیاری در دنیا وجود دارند، اما بسیاری از پروژه های معروف و محبوب دنیا هستند که از گیت استفاده می‌کنند که از آن جمله می‌توان به Linux Kernel، فریم ورک Ruby on Rails و یا فریم ورک jQuery اشاره کرد. علاوه بر این، برخی شرکت های بسیار بزرگ آی تی دنیا نیز از گیت استفاده می کنند که این نشان از موفقیت و برتری نسبی این سیستم نسبت به رقبا دارد. در این آموزش، قصد داریم به برخی از برتری های گیت نسبت به اس وی ان و دیگر سیستم های ورژن کنترل اشاره ای داشته باشیم.

سرعت بالا
از جمله مزایای گیت می‌توان به این نکته اشاره کرد که فوق‌العاده سریع است. علاوه بر این، گیت این امکان را به توسعه دهندگان می‌دهد تا به صورت آفلاین کار کنند، به تاریخچه ی کاملی از نسخه های قبلی پروژه دسترسی داشته و هر تغییری که تمایل داشتند را ایجاد کند، برنچ جدید ایجاد کند و …

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

ایمنی
گیت این اطمینان خاطر را به توسعه دهندگان -مخصوصا غیرحرفه ای ها- می‌دهد که هیچ چیز را روی سرور اصلی نمی‌توان خراب کرد و همین مسأله خیال توسعه دهندگان را تا حد زیادی راحت می کند. در گیت، هر کلونی از پروژه که روی سیستم تک تک توسعه دهندگان قرار دارد یک پروژه ی باثباتی است که کاملاً کار می کند و در صورتی که سرور اصلی هم از دسترس خارج شود، باز هم بکاپی از پروژه روی سیستم تک تک توسعه دهندگان قرار دارد!

کامیت هوشمند
فرض کنیم که در پروژه ی خود در سه فایل مجزا تغییراتی را اعمال کرده ایم. برای سایر اعضای تیم برنامه نویسی کار دشواری خواهد بود تا متوجه شوند چه تغییری در کدام فایل ایجاد شده اما گیت این امکان را به ما می‌دهد تا در هر کامیت، تغییرات مد نظر را شامل کرده تا سایر اعضای تیم به راحتی بتوانند تغییرات را رهگیری کنند.

برنچ های کارآمد
فرض کنیم که شما در حال کار کردن روی بخشی از سورس کد هستید و تا زمانی که تغییرات شما تکمیل نشده اند، سایر توسعه دهندگان نمی بایست تحت تأثیر تغییرات شما قرار گیرند. اینجا است که برنچ ها در سیستم ورژن کنترل گیت جلوی این دست مشکلات را می گیرند. اگرچه سایر سیستم‌ها هم از برنچ ها استفاده می کنند، اما این در حالی است که گیت اولین سیستمی بود که از برنچ ها آن هم به صورتی اثربخش استفاده کرده است.

محبوبیت در میان شرکت های بزرگ حوزه ی آی تی
با توجه به این که شرکت های بزرگی از گیت استفاده می کنند، همین مسأله به منزله ی یکی دیگر از برگ برنده های سیستم ورژن کنترل گیت است چرا که به همین خاطر آموزش‌های بسیار، ابزارهای متنوع و سرویس های زیادی گیت را بیشتر و بیشتر اثربخش خواهند ساخت.

 

[☾♔TALAYEH_A♔☽]

چند نکته ی کاربردی در مورد استفاده از سیستم های ورژن کنترل


زمانی که تصمیم گرفتیم همچون سایر برنامه نویسان حرفه ای، از سیستم‌های ورژن کنترل استفاده کنیم، نیاز است تا یکسری رویکردهایی که به هرچه حرفه‌ای تر شدن ما کمک می‌کنند نیز پایبند گردیم که در این آموزشی به برخی از مهم‌ترین آن‌ها اشاره خواهیم کرد.

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

اعمال تغییرات زیاد روی پروژه و کامیت کردن به مدت مثلاً هفته‌ای یک بار، کار بسیار خطرناکی است چرا که احتمال بروز کانفلیکت را افزایش خواهد داد. سعی کنیم کامیت های مکرر و حساب شده‌ای داشته باشیم.

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

هرگز قبل از تست کردن بخشی از نرم‌افزاری که روی آن کار می کنید، آن را کامیت نکنید. به عبارت دیگر، هرگز به کدهای خود اعتماد کامل نداشته باشید و همواره خود را همچون یکی از کاربران نرم افزار یا اپلیکیشن تلقی کرده و به شکلی آن را تست کنید که گویی یکی از کاربران واقعی نرم افزار یا اپلیکیشن هستید!

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

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

 

[☾♔TALAYEH_A♔☽]

مقدمه‌ای بر شیء گرایی


تا اینجای دوره که با انواع زبان‌های برنامه نویسی، نحوه ی کارکرد آن ها، طراحی سایت، اپ های موبایل و … آشنا شدیم، حال نوبت به بررسی -اگر نگوییم کلیدی‌ترین مبحث- یکی از کلیدی‌ترین مباحث دنیای برنامه نویسی که Object-oriented یا «شیء گرایی» نام دارد می رسد. لازم به ذکر است که در حال حاضر زبان‌های برنامه نویسی سطح بالا که طرفداران زیادی هم در سراسر دنیا دارند اصطلاحاً شیء گرا هستند پس ضرورت آشنایی با این مبحث برای برنامه نویسان مبتدی دوچندان خواهد شد.
در این فصل، تمام تلاش خود را به کار خواهیم بست تا با ذکر مثال‌هایی از دنیای واقعی، به توصیف OOP که مخفف واژگان Object-oriented Programming به معنی «برنامه نویسی شیء گرایی» است بپردازیم. شاید در ابتدا، این اصطلاح کمی گیج‌کننده -و شاید هم برای برخی از دانشجویان ترسناک- به نظر برسد، اما واقعیت چیز دیگری است. به عبارت دیگر، اگر برنامه نویسان مبتدی از همین ابتدای راه به درستی با مفهوم شیء گرایی آشنا شوند، مسلماً از کدنویسی -با هر زبانی- بیشتر لـ*ـذت خواهند برد و به برنامه نویس حرفه‌ای تری مبدل خواهند شد. علاوه بر این، کمتر شرکتی را می‌توان یافت که به استخدام برنامه نویسانی بپردازند که با مفاهیم شیء گرایی -اگر نگوییم تسلط- آشنایی نداشته باشند! به عبارت دیگر، برای ورود به بازار کار برنامه نویسی، آشنایی با اصول برنامه نویسی شی‌‌‌ء گرا یک MUST یا «باید» است.
شاید چیز دیگری که اهمیت این موضوع را دوچندان می‌سازد این باشد که اکثر فریم ورک هایی که برای زبان‌های برنامه نویسی مختلف طراحی می‌شوند نیز بر اساس اصول شی‌ء گرایی طراحی شده اند. در حقیقت، چنانچه بخواهیم از فریم ورکی همچون لاراول که برای زبان برنامه نویسی پی اچ پی طراحی شده برای طراحی وب اپلیکیشن استفاده کنیم اما چیزی از OOP ندانیم، مسلماً نخواهیم توانست کاری از پیش ببریم.

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهوم آبجکت یا شیء در برنامه نویسی شیء گرا


زبان‌هایی همچون اسمبلی، کوبال، فورتران و سایر زبان‌های برنامه نویسی نسبتاً قدیمی به هیچ وجه شیء گرا نبودند و اصطلاحاً تحت عنوان زبان‌های Procedural (پروسیژرال یا پروسه ای) شناخته می‌شوند به طوری که برنامه‌های نوشته شده با این دست زبان‌های پروسه ای، به صورت پروسه‌ای از دستورات پشت سر هم بوده که یکی پس از دیگری اجرا شده و در نهایت برنامه به هدف اصلی‌اش خواهد رسید.

این دست زبان‌های پروسیژرال برای برنامه‌های نسبتاً بزرگ و پیچیده اصلاً مناسب نیستند چرا که مدیریت این دست برنامه‌ها کار بسیار دشواری خواهد بود و هرچه این برنامه ها بزرگ تر شوند، مدیریت آن ها هم سخت خواهد شد.. در چنین شرایطی بود که زبان‌های برنامه نویسی شیء گرا در دهه ۱۹۸۰ شروع به پیدایش کرده و به مرور زمان جای زبان‌های برنامه نویسی پروسیژرال را گرفتند.

برنامه‌ای که پیش از این مثال زدیم، چنانچه با یک زبان برنامه نویسی شیء گرا نوشته شود، سورس کد برنامه به بخش‌هایی مجزا از یکدیگر که تحت عنوان Object (آبجکت به معنی شیء) شناخته می‌شوند تبدیل می شود. به عبارت دیگر، آبجکت ها در یک برنامه‌ای که با زبانی شیء گرا نوشته شده باشد به مثابه ی برنامه‌های کوچک مجزا از یکدیگری می‌باشند که هر کدام کار خاصی انجام داده و در صورتی که در کنار یکدیگر قرار گیرند، تشکیل یک برنامه ی کامل را خواهند داد که هر کدام منطق خاص خود را دارا است اما این در حالی است که با یکدیگر در ارتباط تنگاتنگی خواهند بود.

از یک دید کلی، برنامه نویسی شیء گرا یک پارادایم برنامه نویسی است و به هیچ وجه ربطی به یک زبان برنامه نویسی ندارد بلکه به مفاهیمی مرتبط است که توسط زبان‌های بسیاری من جمله سی پلاس پلاس، جاوا، پایتون، پی اچ پی و … ساپورت می شود. پیش از این که بپرسیم یک آبجکت یا «شیء» در دنیای برنامه نویسی به چه معنا است، ابتدا می بایست بپرسیم که یک شیء در دنیای واقعی به چه چیزی اطلاق می گردد؟

به یاد داشته باشیم که یکی از مهم‌ترین اهداف دانشمندان علوم کامپیوتری از ابداع زبان‌های برنامه نویسی شیء گرا این بوده تا برنامه نویسی را تا حد ممکن به زندگی واقعی نزدیک سازند. به طور مثال، کامپیوتر یا لپ تاپی که با استفاده از آن این دوره از سکان آکادمی را مطالعه می‌کنید یک شیء است. ماوسی که آن را حرکت می‌دهید نیز یک شیء است. اگر از مطالعه ی این آموزش خسته شده‌اید و تمایل دارید یک فنجان چای بنوشید، فنجانی که در دست می‌گیرد هم یک شیء در دنیای واقعی است. چیزی که در مورد این آبجکت ها یا اشیاء می بایست مد نظر قرار دهیم این است که هر کدام از آن‌ها دارای هویتی مجزا از یکدیگر اند. به عبارت دیگر، شیئ همچون فنجان دارای هویتی مجزا از شیئ مثل لپ تاپ است و در دنیای واقعی آن‌ها را دو چیز مجزا از یکدیگر تلقی می‌کنیم که هر کدام کاربرد خاص خود را دارا است.

جالب است بدانیم که در دنیای واقعی یک آبجکت می‌تواند دربرگیرنده ی چندین آبجکت یا شیء دیگر باشد. برای روشن شدن این مسأله مثالی می زنیم. هواپیما یک شیئ است که حاوی چندین شیء دیگر مثل صندلی، در، پنجره، موتور جت، کابین خلبان و … است. موتور جت نیز آبجکتی است که حاوی چندین آبجکت دیگر است که از آن جمله می‌توان به شفت، توربین، سوپاپ، لوله، مخزن و … اشاره کرد.

اکنون که با مفهوم آبجکت ها در دنیای واقعی آشنا شدیم، حال نوبت به بررسی قابلیت‌های آبجکت ها می رسد. هر آبجکت یا شیء در دنیای واقعی دارای یکسری Attribute یا «ویژگی» است. به طور مثال، شیئ هچون لپ تاپ می‌تواند مشکی، هشت هسته ای و با حافظه ی رم هشت گیگابایتی باشد.

اشیاء در دنیای واقعی معمولاً دارای بیش از یک Attribute هستند و این در حالی است که ویژگی‌های اشیاء هیچ ربطی به ویژگی‌های سایر اشیاء ندارد. به عنوان مثالی دیگر، می‌توان میوه ای همچون سیب را در نظر گرفت. یک سیب می‌تواند تازه، قرمز، آبدار، ترش و خوشمزه باشد اما این به هیچ وجه بدان معنا نیست که تمامی سیب های داخل یخچال می بایست از چنین Attribute هایی برخوردار باشند. ممکن است سیب دیگری که در یخچال وجود دارد شیرین، زرد و بدمزه باشد اما به هر حال هر دو سیب اشیائی از یک جنس هستند.

مورد دیگری که اشیاء در دنیای واقعی از آن برخوردارند چیزی است تحت عنوان Behavior به معنی «رفتار یا عملکرد» که کارکرد یک شیء را مشخص می سازد. به طور مثال شیئ هچون هواپیما برای پرواز کردن ساخته شده است اما شیئ همچون ماوس برای کلیک کردن طراحی شده است. این رفتار اشیاء مختص به نوع آن‌ها است. به عبارت دیگر، اشیائی که به یک دسته تعلق دارند از رفتارهای مشابهی برخوردارند اما در عین حال می‌توانند ویژگی‌های متفاوتی داشته باشند.

به طور مثال، هواپیمای Boeing 747 و هواپیمای F16 هر دو از Behavior یکسانی که همان پرواز کردن است برخوردارند اما این در حالی است که Attribute های این دو شیء با یکدیگر کاملاً متفاوت است. به عبارت دیگر، هواپیمای بوئینگ 747 برای مسافربری طراحی شده است اما هواپیمای اف 16 برای جنگ با دشمن طراحی گشته است.

در دنیای کامپیوتر و برنامه نویسی هم آبجکت ها تا حد بسیار زیادی شبیه به اشیاء در دنیای واقعی هستند. هر آبجکت در یک برنامه‌ای که با یک زبان برنامه نویسی شیء گرا نوشته شده باشد دارای خصوصیات مخصوص به خود است، هویتی مجزا از سایر اشیاء موجود در برنامه داشته و رفتار خاصی هم از آن انتظار می رود.

در دنیای واقعی ما به هر چیزی که بتوانیم آن را ببینیم و لمس کنیم لقب شیء می‌دهیم اما در دنیای برنامه نویسی، قضیه تاحدودی متفاوت است. در برنامه نویسی، تاریخ، زمان، یک حساب بانکی و چیزهایی از این دست آبجکت تلقی می شوند. به طور مثال، فرض کنیم که در یک نرم‌افزار بانکی، آبجکتی داریم تحت عنوان BankAccount به معنی «حساب بانکی» که این آبجکت دارای یکسری Attribute ها است که از آن جمله می‌توان به نوع حساب بانکی، شماره حساب و … اشاره کرد. در عین حال، دارای Behavior هایی نیز می باشد. به عبارت دیگر، در یک حساب بانکی می‌توان سپرده گذاشت، پول جا به جا کرد و بسیاری کارهای دیگر. در عین حال، این حساب بانکی از سایر حساب‌های بانکی مجزا است، به عبارت دیگر، این حساب بانکی دارای هویتی منحصر به فرد است.

توجه داشته باشیم که در دنیای برنامه نویسی آبجکت ها همواره نمی بایست قابل روٍئیت باشند. برای روشن‌تر شدن این مسأله مثالی دیگر می زنیم. فرض کنیم که در حال نوشتن یک نرم‌افزار ثبت رویدادها هستیم. یک رویداد چیزی است همچون جشن تولد، عروسی، بزرگداشت و … هیچ کدام از این رویدادها فیزیکی نیستند و به نوعی انتزاعی بوده اما در دنیای برنامه نویسی تحت عنوان آبجکت شناخته می شوند و همان گونه که ما با اشیاء ملموس در دنیای فیزیکی برخورد می کنیم، می توان با آن ها برخورد کرد.

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

 

[☾♔TALAYEH_A♔☽]

آشنایی با مفهوم کلاس در زبان‌های برنامه نویسی شیء گرا


Object ها بدون وجود Class (کلاس) بی‌معنی هستند. واقعیت امر این است که در برنامه نویسی شیء گرایی آنچه مهم است درک مفهوم کلاس است چرا که بدون وجود کلاس ها، هیچ آبجکتی وجود خارجی نخواهد داشت. به عبارت دیگر، ما با استفاده از کلاس‌ها خواهیم توانست به هر تعداد که بخواهیم آبجکت ایجاد کنیم.

یک کلاس مشخص خواهد کرد که شیء مد نظر ما چگونه شیئ خواهد بود اما توجه داشته باشیم که کلاس با آبجکت متفاوت است. کلاس همچون پلان یک ساختمان است. زمانی که ما بخواهیم یک خانه بسازیم، ابتدا می بایست پلان آن را مشخص کنیم. پلان مد نظر شامل کلیه ی جزئیاتی است که مشخص می‌کنند خانه ی ساخته شده چه شکلی خواهد بود اما توجه داشته باشیم که این پلان خود خانه نیست بلکه نقشه ای انتزاعی از خانه ی واقعی است که آن را مورد استفاده قرار داده تا از روی آن، یک خانه ی واقعی بسازیم.

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

در برنامه نویسی شیء گرا، کلاس‌ها دارای نامی منحصر به فرد هستند که نشان دهنده ی ماهیت شان می باشد. علاوه بر این، همان‌طور هم که قبلاً اشاره شد کلاس‌ها دارای Attribute ها و Bahavior هایی هستند که نشان دهنده ی ماهیت شان می باشند. توجه داشته باشیم که در مبحث کلاس ها، عملکردهایی که یک کلاس می‌تواند داشته باشد را در قالب Method (متد) ها بیان می کنیم. به عبارت دیگر، متدها بلوک های کدی هستند که داخل کلاس‌ها قرار داشته، کاری را انجام می‌دهند و در نهایت نتیجه‌ای را در اختیار برنامه نویس قرار می دهند. برای روشن‌تر شدن این مسأله مثالی می زنیم:

فرض کنیم که قرار است یک نرم‌افزار بانکی بنویسیم که در آن کلاسی داریم تحت عنوان BankAccount. این کلاس داری یکسری خصوصیات است که از آن جمله می‌توان به accountNumber و accountType اشاره کرد که به ترتیب به معنی «شماره حساب» و «نوع حساب» می باشند. این کلاس قادر به انجام یکسری کارها است که از آن جمله می‌توان به متدهای ()open و ()close و ()deposit اشاره کرد که به ترتیب به معنی «باز کردن حساب»، «بستن حساب» و «سپرده گذاشتن» می باشند.

این کلاس کاملاً خام است و هیچ کاری نمی‌تواند انجام دهد تا زمانی که یک آبجکت از روی آن بسازیم. این آبجکت ما مثلاً behzadAccount به معنی «حساب بهزاد» نام خواهد داشت که accountNumber آن 136791 بوده و accountType آن هم savingAccount به معنی «حساب پس انداز» است. بهزاد خواهد توانست تا اقدام به باز کردن حساب، بستن حساب و حتی سپرده گذاری در حسابش کند.

به خاطر داشته باشید
در برنامه نویسی شیء گرایی، به هر آبجکت ساخته شده از روی یک کلاس اصطلاحاً Instance یا «نمونه» گفته شده و به فرایند ساخت این نمونه‌ها از روی کلاس‌های مختلف اصطلاحاً Instantiation یا «نمونه سازی» گفته می شود.
پیش از این هم گفتیم که از روی یک کلاس می‌توانیم به تعداد بی نهایت شیء مختلف بسازیم. برای مثال، ما می‌توانیم از روی کلاس BankAccount یک نمونه یا آبجکت دیگر تحت عنوان aliAccount ساخته که شماره حساب آن برابر با 346581 بوده، نوع آن حساب جاری است و صاحب حساب فقط می‌تواند حساب را باز کرده و در آن سپرده بگذارد اما بر خلاف حساب بانکی بهزاد، قادر به بستن آن نیست. درست است که هر دو شیء از روی یک کلاس ساخته شده‌اند اما این در حالی است که هر کدام از اشیاء مد نظر دارای ویژگی‌ها و عملکرد های مخصوص به خود هستند.

حال ممکن است این سؤال برای شما پیش بیاید که آیا یک برنامه نویس همواره موظف است که کلاس‌ها را خودش ایجاد کند؟ در پاسخ به این سؤال بایستی گفت که خیر! بسیاری از زبان‌های برنامه نویسی مطرح دنیا به صورت پیش‌فرض دارای یکسری کلاس‌های آماده هستند که برنامه نویس به سادگی قادر خواهد بود تا به هر تعداد که تمایل داشته باشد از رویش آبجکت بسازد. فریم ورک های زبان‌های برنامه نویسی مختلف که پا را از این هم فراتر گذاشته و علاوه بر کلاس‌های از پیش نوشته شده در خود زبان برنامه نویسی، یکسری کلاس‌های دیگر هم به منظور افزایش قابلیت‌ها به آن زبان اضافه می کنند. به طور مثال، از جمله کلاس‌های از پیش تعریف شده در زبان‌های برنامه نویسی می‌توان به کلاس‌های مرتبط با تاریخ، استرینگ ها و … اشاره کرد.

به مجموعه کلاس‌های از پیش نوشته شده در یک زبان برنامه نویسی اصطلاحاً Library (لایبرری یا کتابخانه) گفته می شود. برای مثال، در لایبرری زبان برنامه نویسی جاوا چیزی در حدود 4000 کلاس از پیش نوشته شده وجود دارد که روز به روز هم در نسخه های جدید زبان جاوا به این تعداد افزوده می شود.

اما به هر حال، زمان هایی در توسعه ی برنامه‌ها پیش می‌آید که کلاس‌های از پیش نوشته شده نیاز برنامه نویس را برآورده نکرده و این خود برنامه نویس است که می بایست اقدام به ایجاد یک کلاس کند که در آموزش بعد، با این چالش برنامه نویسان بیشتر آشنا خواهیم شد.

 

[☾♔TALAYEH_A♔☽]

آشنایی با چهار اصل برنامه نویسی شیء گرا


پس از آن که در آموزش‌های گذشته با مفاهیمی همچون کلاس و آبجکت آشنا شدیم، حال نوبت به آن رسیده تا ببینیم که بر اساس چه اصولی می‌توان به صورت علمی اقدام به ساخت کلاس‌های مختلف و بالتبع آبجکت هایی از روی آن کلاس‌ها کنیم. به طور کلی، در برنامه نویسی شیء گرا چهار اصل پایه‌ای برای ساخت کلاس‌ها وجود دارد که عبارتند از:

Abstraction
Polymorphism
Inheritance
Encapsulation

برای به خاطر سپردن این چهار اصل، می‌توان ابتدای هر یک از این مفاهیم را در کنار یکدیگر قرار داده و کلمه ی A PIE را به خاطر سپرد. اگرچه این مفاهیم در ابتدای امر کمی ترسناک و ناامید کننده به نظر می رسند، اما واقعیت این است که ما به صورت ناخودآگاه با این مفاهیم آشنا بوده و می‌شود گفت که هر روز با آن‌ها سروکار داریم. در ادامه، با تک تک این مفاهیم در قالب مثال‌هایی کاربردی از دنیای واقعی آشنا خواهیم شد.

Abstraction
فرض کنیم در اتاقی نشسته‌ایم و فردی از ما می‌پرسد که لپ تاپ کجاست؟ ما هم جواب فرد مد نظر را داده و می‌گوییم روی «میز» است. وقتی ما واژه ی میز را به زبان می آوریم، هرگز نمی‌گوییم که لپ تاپ روی میزی است که چوبی است، رنگ آن قهوه ای روشن است، روی آن یک شیشه قرار دارد، چهار پایه دارد، طول و عرض آن فلان اندازه است و … ما صرفاً واژه ی میز را به زبان آورده و طرف مقابل کاملاً متوجه می‌شود که منظور ما کدام میز است! هم ما و هم طرف مقابل مان که در اتاق حضور داریم تجربیاتی در برخورد با شیئ به نام «میز» داشته و داریم که به ما کمک کند تا منظور از میز را متوجه شویم. واژه ی Abstraction به معنی «انتزاعی بودن» است. یعنی چیزی که در حد یک ایده است و وجود خارجی ندارد یا این که نمی‌شود آن را لمس کرد.

در برنامه نویسی شیء گرا، Abstraction به این قضیه اطلاق می‌شود که ما به جای تمرکز روی یک نمونه ی عینی از چیزی، روی مفهوم چیزها متمرکز شویم و مفهومی کلی را در نظر بگیریم. Abstraction به مفهومی انتزاعی در ذهن برنامه نویس گفته می‌شود که کلی است و هیچ ارتباطی با یک آبجکت خاص ندارد.

همان‌طور که گفتیم، ما این چهار اصل در برنامه نویسی شیء گرایی را به طور ناخودآگاه در زندگی روزمره ی خود به کار می‌بریم و جالب است بدانیم که قلب برنامه نویسی شیء گرایی نیز همین Abstraction است. در‌ واقع، وقتی که ما یک کلاس می سازیم، داریم به صورت انتزاعی و مفهومی، ایده ای را می پرورانیم که هیچ وجود خارجی ندارد تا این که یک شیء از روی آن کلاس ایجاد کنیم.

Abstraction حاکی از آن است که ما اصلاً نیازی نیست تا یک کلاس برای BehzadAccount و کلاس دیگری برای AliAccount بسازیم بلکه یک کلاس مفهومی تحت عنوان BankAccount خواهیم ساخت که از روی آن می‌توان به تعداد بی نهایت آبجکت ایجاد کرد.

Encapsulation
این مفهوم از واژه ی Capsule که به همان کپسولی اطلاق می‌شود که وقتی مریض می‌شویم میل می کنیم گرفته شده است. کپسول چیزی است که غشایی دور چیزی یا چیزهای خاصی ایجاد می‌کند تا علاوه بر دور هم نگه داشتن آن‌ها در کنار یکدیگر، از آن ها محافظت نیز کند.

در برنامه نویسی، Encapsulation به زمانی اطلاق می‌شود که ما Attribute ها وBehavior های یک آبجکت را در کپسولی فرضی قرار داده و آن‌ها را کنار یکدیگر قرار دهیم. علاوه بر این، با به کارگیری مفهومی تحت عنوان Encapsulation ما خواهیم توانست دسترسی به بخش یا بخش‌هایی از یک کلاس یا آبجکتی که بر اساس آن کلاس نوشته شده را محدود کنیم. در مثال حساب بانکی، فرض کنیم ویژگی‌هایی داریم همچون شماره حساب و موجودی. از این دو صرفاً شماره حساب است که می‌تواند در اختیار سایر بخش‌های نرم‌افزار قرار گیرد و این در حالی است که سطح دسترسی به ویژگی موجودی با مفهومی همچون Encapsulation محدود شده است.

حال ممکن است این سؤال برای برنامه نویسان مبتدی پیش بیاید که اگر من خودم اقدام به ساخت یک کلاس می کنم، چه لزومی دارد که بخش یا بخش‌هایی از کلاس ساخته شده را از خودم پنهان کنم؟ در پاسخ به چنین سؤالی بایستی گفت که در اینجا قضیه پنهان کاری و … نیست، بلکه در اینجا منظور به حداقل رساندن وابستگی میان بخش‌های مختلف برنامه است. در چنین شرایطی، ایجاد یک تغییر کوچک در کلاس مد نظر -مثلا محدود کردن سطح دسترسی به برخی قابلیت‌های کلاس- فوراً روی تمامی آبجکت های ساخته شده از روی این کلاس اعمال خواهد شد. در ادامه، ممکن است سؤال دیگری به ذهن خطور کند که تا چه حدی می بایست این خصوصیات را از دید سایر بخش‌های برنامه پنهان ساخت؟ که در پاسخ به این سؤال هم بایستی گفت که هرچه بیشتر، بهتر!

زبان‌های برنامه نویسی شیء گرای مختلف، تعریف مخصوص به خود را در ارتباط با مفهوم Encapsulation یا پنهان سازی بخش‌هایی از کلاس از دید سایر بخش‌های نرم‌افزار دارند. آنچه در اینجا حائز اهمیت می‌باشد این است که مفاهیمی همچون Abstraction و Encapsulation در کنار یکدیگر، این فضا را برای ما -به عنوان برنامه نویس- ایجاد می‌کنند تا به هر میزانی که تمایل داشته باشیم مفاهیمی انتزاعی ایجاد کرده تا در آینده به هر میزان سطح دسترسی که تمایل داشته باشیم از روی آن‌ها اشیائی خاص بسازیم.

Inheritance
در ساده‌ترین شکل ممکن، Inheritance را می‌توان به «استفاده ی مجدد از کدهای از قبل نوشته شده» ترجمه کرد. معنی لغوی Inheritance «وراثت» است. برای روشن‌تر شدن این مسأله مثالی عملی می زنیم. فرض کنیم که در نرم‌افزار خود، ما کلاسی ایجاد کرده‌ایم تحت عنوان Person به معنی «انسان» که دارای یکسری خصوصیات است که از آن جمله می‌توان به name, phoneNumber و email اشاره کرد که به ترتیب به معنی «نام»، «شماره تلفن»، «ایمیل» اند. این کلاس دارای یکسری عملکرد نیز هست که به طور مثال می‌توان به متدی تحت عنوان ()changeEmail یا قابلیت «تغییر آدرس ایمیل» اشاره کرد. اکنون قصد داریم اقدام به ساخت کلاس جدیدی کنیم مثلاً تحت عنوان Customer به معنی «مشتری» که این کلاس دقیقاً شبیه به کلاس Person است. به عبارت دیگر دارای خصوصیاتی مثل name, phoneNumber و email است و همچنین عملکردی تحت عنوان ()changeEmail نیز دارا است. علاوه بر این موارد، کلاس مشتری دارای Attribute یی تحت عنوان customerNumber به معنی «شناسه ی مشتری» است که کلاس انسان فاقد آن است.

در چنین شرایطی ما دو راه‌ کار پیش رو داریم: راه‌ کار اول این که یک کلاس جدید همچون کلاس Person ساخته سپس قابلیت customerNumber را به آن اضافه کنیم یا این که کلاس جدیدی تحت عنوان Customer ساخته، صرفاً قابلیت customerNumber را در آن قرار داده سپس کاری کنیم که این کلاس جدید سایر خصوصیات و قابلیت هایش را از کلاس Person اصطلاحاً «به ارث ببرد» که این همان چیزی است که زبان‌های برنامه نویسی شیء گرا برای آن ساخته شده اند.

از این پس، کلاس مشتری کلیه ی قابلیت‌های کلاس انسان را دارد و جالب است بدانیم در صورتی که تغییری در کلاس انسان ایجاد کنیم، کلیه ی آن تغییرات در کلاس مشتری نیز اعمال خواهند شد. حال ممکن است این سؤال برای شما پیش بیاید که چرا از همان ابتدا چیزی مثل customerNumber را داخل کلاس انسان قرار ندادیم. پیش از این هم توضیح دادیم که ما در برنامه نویسی شیء گرا می بایست تا حد ممکن به اولین اصل یا همان Abstraction احترام بگذاریم و کلاس‌هایی که ایجاد می‌کنیم می بایست تا حد ممکن کلی باشند. اگر ما چیزی مثل شناسه ی مشتری را داخل کلاس انسان قرار می دادیم، این کلاس را تا حدودی محدود می کردیم. فرض کنیم که در آینده شرایطی ایجاد می‌شد که مجبور می‌شدیم که کلاسی تحت عنوان Seller به معنی «فروشنده» ایجاد می کردیم. در چنین شرایطی اگر کلاس Seller از کلاس Person ارث بری می کرد، دارای قابلیتی همچون customerNumber بود که این ویژگی به هیچ وجه به درد اشیاء ساخته شده از روی کلاس Seller نمی خوردند.

به خاطر داشته باشید
در برنامه نویسی شیء گرایی، کلاس Person تحت عنوان Superclass یا «کلاس اصلی» و کلاس Customer تحت عنوان Subclass یا «کلاس زیرشاخه» شناخته می شود. از یک بعد دیگر، کلاس Person را می‌توان کلاس Parent یا «والد» و کلاس Customer را می‌توان کلاس Child یا «فرزند» تلقی کرد.
در زبان‌هایی همچون ++C این امکان در اختیار برنامه نویس قرار گرفته تا بتواند از بیش از یک کلاس والد ارث بری کند که چنین قابلیتی تحت عنوان Multiple Inheritance یا «وراثت چندگانه» شناخته می شود. اگر چه چنین قابلیتی دست برنامه نویسان را خیلی باز می گذارد، اما در عین حال چنین قابلیتی منجر به پیچیده‌تر شدن برنامه می‌گردد و به همین دلیل است که برخی زبان‌های برنامه نویسی همچون جاوا، سی شارپ، آبجکتیو سی، روبی و … به هیچ وجه اجازه ی ارث بری از بیش از یک کلاس والد را به برنامه نویس نمی دهند.

Polymorphism
آخرین اصل از اصول برنامه نویسی شیء گرا Polymorphism نام دارد. Poly به معنی «چندین» است و Morph هم به معنی «شکل» است که روی هم رفته می‌توان آن را به «چند شکلی» ترجمه کرد. این اصل در مقایسه با سه اصل اول اصول شیء گرایی کمی پیچیده‌تر است اما سعی می‌کنیم با مثال‌هایی ملموس، مفهوم Polymorphism را برای برنامه نویسان مبتدی روشن کنیم.

در ابتدا مثالی از این اصل می‌زنیم که شاید تا به حال خیلی در مورد آن فکر نکرده باشیم. علامت + را در نظر بگیرید. علامت + به چه معنا است؟ در بسیاری از زبان‌های برنامه نویسی این علامت دارای کاربردهای متنوعی است. اگر ما بخواهیم دو متغیر همچون a و b را با علامت + به صورت a + b در کنار یکدیگر قرار دهیم، بسته به این که این متغیرها چه مقداری داشته باشند، از علامت + می بایست انتظار عملکردی متفاوت داشته باشیم. به طور مثال، اگر مقدار متغیر a برابر با 7 و مقدار متغیر b برابر با 2 باشد، علامت + حاصل جمع جبری این دو متغیر که برابر با عدد 9 است را محاسبه خواهد کرد. حال فرض کنیم مقادیر مرتبط با این دو متغیر استرینگ باشند. به عبارت دیگر، مقدار متغیر a برابر با 'Behzad' و مقدار متغیر b برابر با 'Moradi' باشد که در چنین شرایطی علامت + به هیچ وجه حاصل جمع متغیرها را در اختیار ما قرار نخواهد داد بلکه این دو استرینگ را در کنار یکدیگر قرار داده و نتیجه ی 'BehzadMoradi' را در اختیار ما قرار می‌دهد که به چنین چیزی در برنامه نویسی اصطلاحاً Concatenation به معنی «الحاق» گفته می شود.

نکته
String (استرینگ به معنی رشته) به نوع خاصی از کلاس ها در برنامه نویسی گفته می شود که می توانند دربرگیرنده ی هر نوع داده ای از حروفی مثل a, F, GG گرفته تا علائمی همچون !, % و * باشند.
در‌ واقع، از مثال فوق این نتیجه را می‌توان گرفت که علامت + بسته به این که چه نوع دیتایی در اختیارش قرار گیرد، عملکرد متفاوتی از خود نشان خواهد داد. در مورد اول، عملکردش به این شکل است که مقادیر متغیرها را جمع جبری می‌کند و در مورد دوم، مقادیر را در کنار یکدیگر قرار می دهد.

با در نظر گرفتن این مقدمه، حال قصد داریم ببینیم که اصل چند شکلی در شیء گرایی چگونه نمود عینی پیدا خواهد کرد. مجدد به مثال حساب بانکی باز می گردیم. فرض کنیم که یک Superclass داریم تحت عنوان BankAccount که دارای یکسری Attribute مثل accountNumber و accountType به ترتیب به معنی «شماره حساب» و «نوع حساب» است. این کلاس علاوه بر این دارای یکسری Behavior نیز هست که از آن جمله می‌توان به متدهایی همچون ()open و ()close و یا ()withdraw به ترتیب به معنی «باز کردن حساب»، «بستن حساب» و «برداشتن موجودی» می باشد.

فرض کنیم که قصد داریم یکسری کلاس جدید ایجاد کنیم مثلاً با نام های InvestmentAccount و SavingAccount و CurrentAccount به معنی «حساب سرمایه گذاری»، «حساب پس انداز» و «حساب جاری». این حساب‌های بانکی همگی قابلیت‌هایی همچون باز و بسته کردن حساب، برداشت موجودی و یا شماره ی حساب و نوع حساب را دارند پس به سادگی می‌توانیم برنامه ی خود را طوری بنویسیم که این کلاس‌ها از کلاس اصلی قابلیت هایشان را به ارث ببرند اما توجه داشته باشیم که هر کدام از این کلاس‌ها دارای یکسری ویژگی‌های مخصوص به خود هستند. به طور مثال، حساب پس انداز می بایست دارای چیزی همچون interestRate یا «بهره ی بانکی» باشد که حساب‌های سرمایه‌گذاری و جاری فاقد آن هستند. اما قضیه به اینجا ختم نشده و شرایط تاحدودی پیچیده‌تری از آن چیزی است که در ظاهر به نظر می رسد. فرض کنیم بانکی که سفارش این نرم‌افزار را به ما داده است، قانونی گذاشته مبنی بر این که اگر یک مشتری از حساب سرمایه‌گذاری خود تا قبل از یک سال پولی برداشت کند، می بایست 30 درصد جریمه دهد اما مشتریانی که حساب پس انداز یا جاری دارند، به سادگی و بدون هیچ جریمه ای هر وقت که تمایل داشته می‌توانند Withdraw کنند یا «از حساب خود پول برداشت کنند».

متد ()withdraw در کلاس والد تعریف شده است اما این در حالی است که ما در کلاس حساب سرمایه گذاری، خواهیم توانست نوع خاصی از آن متد را ایجاد کنیم که چنین کاری اصطلاحاً در برنامه نویسی Override یا «رونویسی» گفته می شود. به عبارت دیگر، ما متد ()withdraw که در کلاس BankAccount قرار دارد را در کلاس InvestmentAccount اصطلاحاً Override کرده و انتظارات مد نظر خود را در آن می گنجانیم که صرفاً مخصوص کلاس InvestmentAccount اند. به طور خلاصه، زمانی که ما بخواهیم چیزی را از کلاس دیگری استفاده کنیم، به سادگی آن را به ارث می‌بریم اما اگر بخواهیم تغییری در این ارث بری ایجاد کنیم، Attribute یا Behavior مد نظر را Override می‌کنیم.