خالی از لطف نیست که به این پست از یکی از دوستان خوبمون اشاره بکنم.

یک کامنتی برای این پست خواستم بگذارم که مسائل رو شفاف تر کنم.

پارت 2 آموزش راجب معماری برنامه بود.
تو این بخش راجب نوع های scale کردن سیستم هم صحبت میشه.
در اصل دو نوع scale کردن داریم.

یکی عمودی (Vertical) که تو این نوع شما سخت افزار رو قوی میکنید که کاهش بازده داره نسبت به قیمتی که باید صرف کنید.
و قطعا به یه جایی میرسید که دیگه سخت افزار قوی تری نمیتونید بگیرید.

نوع دوم افقی (Horizontal) که شما میاید و به چند ها سرور تقسیم میکنید. هر سروری یک مسئولیت داره.
حتی در مواردی دیتابیس رو هم روی یک سری سرور ها تکثیر میکنید یا حتی اگر خیلی دیتا سنگین بشه تقسیم کنید.

دید و تئوری کلی مبحث System Design همینه.
کلی جزییات هم داره که در سطوح back-end قطعا باید اطلاع داشته باشن ولی فرانت اند کار صرفا باید بینشش رو داشته باشه و همین کافیه.

در بخش 15 و 16 که از SQL و NoSQL صحبت میشه.
دوستان فکر نکنن که SQL قدیمی شده. درسته که scale کردن سیستم ها با SQL خیلی سخت هست.
ولی زمانی که سیستم ما نیاز به کل ساختار ACID داشته باشه خیلی SQL حیاتیه.

مثل بانک ها، سیستم های معاملاتی و حسابداری، رکورد های پزشگی و خیلی سیستم ها با اطلاعات مهم یا نیازمند تاخیر کم.
تو پست بعدیم راجب ACID صحبت میکنم.

گوگل برای یوتیوب از MySQL استفاده میکرد و به کلی چالش های مهندسی خورد.
مجبور شد Vitess رو بسازه که منطق sharding از لایه برنامه حذف کنه تا برنامه های روی سرورشون پیچیده نشن.

اینجا یه خلاصه ای از داستانش رو نوشتن که جالب هست.

جدا از اون تو بخش 19 که راجب Object Storage صحبت میشه.
منظور از دیتا باینری همون عکس، فیلم و هر چیزی که نوشتاری نباشه هست.
البته که واسه استفاده های ساده همون داخل دیسک ذخیره کنید و آدرس رو فقط داخل دیتابیس ذخیره داشته باشید کافیه.
(البته باز این موضوع باز قابل بحث هست و راه حل های بهتری هم میتونه وجود داشته باشه)

سرویس های Object Storage مثل Amazon S3 و Google Cloud Storage هستن.
که قطعا هزینه هنگفتی دارن و واسه استفاده های بزرگ طراحی شدن. (حالا پروسه خریدش بماند)
تو ایران هم یه چند تایی داریم که یکیشون احتمالا خودتون میدونید. :)

راه حل های اوپن سورس و self-hosted هم داریم.
اما هیچ کدوم رو امتحان نکردم.

خیلی وقته که دیگه فرانت اند یا بک اند کار خام معنا نداره.

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

ویدیو آخر آموزش System Design for Beginners که اسمش MapReduce بود رو پیدا کردم و تو کانال پین شده قرار دادم.

Have fun ;)

خب بیاید راجب ACID صحبت کنیم.
این مفهوم پایه همه دیتابیس های رابطه ای یا همون SQL هست.

1. همه چی یا هیچ چیز (Atomicity):
هر تراکنش یا کامل میشه و ثبت میشه یا اصلا کامل نمیشه.
اگر وسط تراکنش برق بره هیچ دیتایی تغییر نکرده.
منطور از تراکنش هر موقعی هست که شما commit رو میزنید.
اگر کامیت نکنید در واقع چیزی ثبت نشده.
ممکنه یک تراکنش حاوی چند دستور SQL باشه.

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

اطلاعات بیشتر

2. ثبات دیتا (Consistency):
تمام قید و شروط جدول ها از جمله کلید های خارجی و ... برای هر تراکنش بررسی میشن.
برای بعضی از سیستم ها این خیلی اهمیت داره. (شما موجودی منفی بانک رو دوست ندارید قطعا)
تو NoSQL کلید خارجی نداریم ولی جایگزین هایی وجود دارن (ریفرنس).
حتی قید هایی هم برای دیتا ها داخل NoSQL وجود داره اما کمتر از SQL هست.

اطلاعات بیشتر

3. جدایی تراکنش ها (Isolation):
اگر با multi threading آشنا هستید احتمالا میدونید که منظورم چیه.
یعنی قابلیت پردازش همزمان تراکنش ها بدون اینکه یک تراکنشی تراکنش دیگه رو تحت تاثیر قرار بده.
تو multi threading شما از Mutex یا Semaphore استفاده میکنید.
داخل دیتابیس از Lock (Shared, Exclusive) استفاده میکنید.
هر بار که سطری میخواد تغییر کنه قفل میشه.
بعد از انجام شدن باز میشه تا در صورت نیاز تغییرات دیگه اعمال بشه.
از اونجایی که تراکنش ها تو صف هستن سر همین هر وقت که سطری آزاد بود اعمال میشن.

اطلاعات بیشتر

4. ماندگاری (Durability):
تراکنش های ذخیره شده برای همیشه در حافظه سخت میمونن و با قطع برق از بین نمیرن.
ولی خب وقتی یک صف از تراکنش باشه که در انتظار پردازش باشه قطعا باید مکانی برای ذخیره سریع این تراکنش ها باشه که از بین نرن.

بله. به بحث logging خوش اومدید.
یه چیزی داخل دیتابیس ها داریم به اسم Fast Transaction Log که تراکنش هارو به سرعت بالایی ذخیره میکنه (چون append-only هست. سر همین زیاد دیسک درگیر نمیشه).

وقتی برق میره و برمیگرده دیتابیس از حالت پایدار قبلی به حالت پایدار بعدی میره (حالت فعلی پایدار نیست چون دیتابیس عملیات های تمام نشده داره). یعنی تراکنش های مونده رو پردازش میکنه.

اطلاعات بیشتر

خب دوستان گفتم یه خبری بدم که چه میگذره.

دارم دوره PySide6 میبینم.
کتابخونه گرافیکی هست که یه wrapper (یا لایه ارتباط) برای Qt به زبان پایتون عه.
و تمام قابلیت های Qt رو داره و از شرکت Qt توزیع شده.
اینو اختصاصی برای کارایه خودم دارم میبینم و چیزی نیست که بخواید سمتش برید و یاد بگیرید.
خیلی هم نمونده که تموم بشه.
(دوره اش هم خیلی عمیق نیست و کیفیت عالی نداره ولی کارو جواب میده و نسخه کوچک ترش هم تو freecodecamp هست)

و اما بخش مهم:

جدا از اون دارم OOP Design Pattern هم یاد میگیرم.
اگر تو پروژه ای هستید که به شدت با شی گرایی سروکار دارید
(مثل من که با framework گرافیکی کار میکنم).
این دوره جزو دوره های مهمی محسوب میشه.

در غیر اینصورت سمتش نیاز نیست برید.
چون تو اولویت اول نیست.

در نهایت دوره ای که پلن دارم تو آینده نزدیک نگاه کنم PyTorch هست.

واستون لینک و فایل تورنت همشون رو داخل کانال پین شده گذاشتم.

سلام دوستان.

به خاطر یک سری مشغله ها و deadline ها چند وقتی نمیتونستم پست با کیفیتی بزارم.

آموزش OOP Design Pattern neetcode و همینطور PySide6 تموم شدن و در حال حاظر مشغول دیدن آموزش PyTorch هستم.

ممنون که با من همراه هستید.

دو روز دیگه میخوام یه پست راجب دوره System Design Interviews بزارم (یادم نرفته بود، صرفا فرصت نشد).

همینطور یک نقد مثبتی از OOP و Design Pattern.

و در نهایت یه نقد منفی از OOP و تجربه های خودم در این زمینه.

خب. راجب Neetcode System Design Interview:

اولین نکته ای که باید تو هر مصاحبه ای رعایت کنید اینه که اگر جزییات کار مشخص نیست از مصاحبه گر حتما بپرسید.
چون بدترین چیز تو زمان مصاحبه اینه که مسئله اشتباهی رو حل کنید.

همه مصاحبه های سیستم دیزاین شامل چهار بخش میشن.

Background
پیش زمینه های مورد نیاز راجب سیستم رو توضیح میدید. اینکه چی هست، چه چیزی به کاربران ارائه میده.
البته تو ویدیو های NeetCode این بخش با Non-Functional Requirements ممکنه کمی قاطی بشه.

Functional Requirements
سیستمی که میخوایم طراحی کنیم چطور کار میکنه. فیچر هایی که سیستممون باید داشته باشه.
مثلا تو مثال توییتر مثل news feed یا like یا dislike. هر چیزی که مرتبط با کاربر هست.

Non-Functional Requirements
هر چیزی که Functional Requirements نیست. ولی خب دقیق تر بخوام بگم.
هر چیزی که مربوط به scalability هست. مثلا چقدر سرویس ما یوزر خواهد داشت. هم تو لانچ و همینطور در آینده (باید آینده نگر باشیم تا اگر نیاز شد مقیاس سیستم ما بالاتر بره بدون مشکل ارتقا رو انجام بدیم).
دیتابیس ما چقدر read یا write انجام میده و نسبتشون چقدره؟
چقدر فضای ذخیره سازی نیاز داریم؟ چقدر availability (دسترسی پذیری) میخوایم؟
سرویسمون چقدر تاخیرش باید پایین باشه.
نکته: معمولا تو محاسبات تخمین زده میشه. بنابراین لازم نیست دقیق بدست بیارید.

High Level Design
طولانی ترین بخش مصاحبه این بخش هست.
تو این بخش تمام اطلاعات قبل رو به کار میبندید تا یک دیزاین مناسب این سیستم ارائه بدید.
یادتون باشه که مصاحبه گر دنبال پاسخ خاصی نیست.
مصاحبه گر میخواد بدونه که شما توانایی تحلیل یک سیستم رو دارید؟

تو این مرحله از هر جایی که صلاح دیدید شروع میکنید.
یک شمای کلی از سیستم.
نه لازم نیست UML بکشید. صرفا واسه نشون دادن اینه که چه چیزایی میخواید تو سیستمتون بکار ببرید.

اول راجب سرور یا API سرور صحبت میکنید اگر بخش مهم یا اصلی سرویستون هست.
اینکه چه endpoint هایی رو برای اون بخشی که طراحی میکنید در نظر گرفتید. قاعدتا مصاحبه گر ازتون نمیخواد کل توییتر رو تویه 45 دقیقه طراحی کنید (اگر خواست یعنی مصاحبه گره مشکل داره).
معمولا یکی یا دو تا فیچر رو ازتون میخوان. سر همین هستش که حتما با پرسش مسئله رو شفاف تر کنید.

همینطور انتخاب دیتابیس هم مهم هست. SQL باشه یا NoSQL. حتی NoSQL ها هم با هم متفاوت ان. مثلا Cassandra دیتابیسی مخصوص سرعت write بالا هست (از اونجایی که از LSM-Tree و SSTables استفاده میکنه).

تو مصاحبه میتونید راجب تفاوت های ظریف هم صحبت کنید. مثلا میتونیم از فلان چیز استفاده کنیم و سیستم رو سریع میکنه ولی موجب مشکلات دیگه میشه. گفتن اینا مصاحبه کننده رو آگاه میکنه که میتونید گزینه ها رو سبک و سنگین کنید و مزیت و عیب های هر روش رو تشخیص بدید که خیلی اهمیت داره.

همینطور از بخش Caching قافل نشید. یک سری سیستم ها حتما نیاز به Cache دارن که تا بتونن تجربه کاربران رو بهتر کنن و تاخیر متوسط رو پایین بیارن. جدا از اون این بخش خیلی کیف میده و مطمئنم مصاحبه گر ها هم کیف میکنن.

تو مثال هایی هم استفاده از WebSocket خیلی سرعت رو بالا میبره و تاخیر رو پایین میاره.
تو دیسکورد مثلا از WebSocket برای ارسال پیام و نوتیفیکیشن هاش استفاده میکنه.

یادتون باشه شما Domain Expert نیستید تو همه اینا.
قطعا از شما نمیخوان که از جزییات همه این بخش ها سر دربیارید.
شما فقط دارید سیستم طراحی میکنید.

حال راجب تک تک ویدیو هاش و نکات جالبش صحبت میکنم.

1. How to Approach:
تو ویدیو اولش راجب اینکه چطوری مصاحبه های سیستم دیزاین رو هندل باید بکنید صحبت میشه.
تو پست قبلی راجب این موضوع هم خودم صحبت کردم.

2. Design a Rate Limiter:
راجب دیزاین یک Rate Limiter صحبت میشه. در واقع Rate Limiter ای که دیزاین میشه جنریک هست. یعنی برای هر سیستمی با هر مقیاسی در نظر گرفته میشه.
و اینکه بله. Rate Limiter میتونه یه سیستم با چندین کامپیوتر باشه. برای منم جالب بود.

یک جایی Rule ها ذخیره میشن (دیتابیس). یک بخشی هم Memory Store (Cache) باشه.

همینطور الگوریتم های مختلفی که یک Rate Limiter میتونه داشته باشه مثل Fixed Window یا Sliding Window.

3. Design TinyUrl:
در نگاه اول فکر میکنید که دیزاین این موضوع خیلی خنده دار و ساده هست.
اما کامل در اشتباهید. وقتی که scale بالا بره هر چیز ساده ای تبدیل به چالش میشه ;)
تو این سرویس read به شدت بالا هست و سر همین دیتابیس کاملا درگیره. سر همین باید لینک هایی که آزاد برای استفاده هست رو یک جای دیگه ذخیره کنید و ...
تازه یه worker هم باید برای حذف لینک های منقضی شده هم باید گذاشت.

4. Design Twitter:
بخش Feed هر کسی میتونه با یه سرویس Message Queue ساخته شه که شامل Cluster هایی هستن که feed ما رو جنریت میکنن و داخل یه Cache بزرگ ذخیره میکنن.

دیتابیس؟ چرا؟ مگه قراره فید رو تا ابد ذخیره کنیم؟ تازه فید ها هم آپدیت میشن سر همین ذخیره سازی تو دیتابیس اشتباهه.

جدا از اون دیتابیس توییتر جای NoSQL میتونه GraphDB باشه. البته که من شخصا راجب محدودیت های GraphDB اطلاعات ندارم ولی خب آپشنی هست که میتونه بررسی بشه.

5. Design Discord:
اینجاست که WebSocket میدرخشه و اینکه اونقدر نسبت write به read بالاست که حتی دیتابیس های NoSQL معمول هم جواب نمیدن.
باید سمت دیتابیس های مخصوص write بالا رفت. مثل Cassandra یا حتی ScyllaDB که سال پیش روی اون سویچ کردن.

البته که دیسکورد قبل از اینکه روی Cassandra سویچ کنه از MongoDB استفاده میکرد. بنابراین همون اول هم نیاز نیست مقیاس عظیم بسازید. اول زنده بمونید و راه رو برای مقیاس های بزرگ تر باز بزارید.

6. Design YouTube:
قاعدتا یوتیوب نیاز به Object Storage داره. در غیر اینصورت چطور میخواد این همه ویدیو سنگین رو ذخیره کنه؟
جدا از اون نیاز به یه لشکر worker عظیم و Message Queue داره که ویدیو ها رو انکود کنه و باز داخل Object Storage ذخیره کنه. و خود ویدیو های هم روی CDN باید باشن که دسترسی بهشون خیلی سریع باشه.

تو این سیستم از WebSocket استفاده نکردن و صرفا ویدیو ها رو قطعه قطعه میفرستن.

و راجب دیتابیس هم واقعا از NoSQL استفاده نمیکنن. بلکه از MySQL استفاده میکنن و شاید بپرسید چطور؟ با اون دیتای عظیمی که دارن دیتابیس رو چطوری shard میکنن؟
با استفاده از ابزار خودشون. و قبل از این هم منطق sharding رو روی بخش کد های سرورشون پیاده میکردن.

7. Design Google Drive
دو حالت واسه دیزاینمون داریم. یکیش Distributed File System و دیگری Object Storage.
با Distributed File System دیزاین خیلی پیچیده تر میشه و به اندازه Object Storage مقایس پذیری نداره.
ولی خب تو این آموزش چون بخش ادیت در نظر گرفته نشده سراغ Distributed File System نمیره. ولی خب خواستید بررسی کنید ابزار هایی مثل Apache Hadoop هست.
جدا از اون اگر بخوایم با Object Storage بریم باید دیتا رو بلوک بندی کنیم و همین به ما اجازه deduplication میده. یعنی میتونیم فایل های تکراری یا بخش های تکراری رو فقط یک بار ذخیره کنیم.
واسه حذف هم یه سرویس Garbage Collection میتونیم بزاریم که یه بار میگرده و بخش هایی که استفاده نمیشن رو حذف میکنه.

8. Google Maps:
اینجا متوجه میشید که چقدر domain knowledge مهم هست تو دیزاین سیستم ها.
الگوریتم های مسیریابی، نحوه ذخیره سازی نقشه ها. اطلاعاتی مرتبط با نقشه و ...
سرویس مسیریابی و مکان یابی جدا ان و بخش مکان یابی میتونه برای ارائه گزارشی از ترافیک های محل از یه Message Queue استفاده کنه و پردازش رو روی دیتا های محل کاربران انجام بده و داخل دیتابیسی به اسم ترافیک ذخیره کنه.

9. Design a Key-Value Store:
اینجا قشنگ با مفاهیم پیچیده بمبارون میشید.
به قولی ادامه مباحث NoSQL تو آموزش قبلی هست ولی در فرمت مصاحبه.

10. Distributed Message Queue:
یه Message Queue ساده که روی یک کامپیوتر پیاده میشه بلاخره محدودیت هایی داره.
ولی بیشتر وقتی معماری رو توزیع شده بسازیم میتونیم محدودیت ها رو دور بزنیم.

بخش Discussion اضافه شد.
Have fun ;) and behave

سلام دوستان.
چند وقت پیش میخواستم راجب OOP و Design Pattern و کلاً معایب و مزایای OOP پست بزارم.
ولی خب گفتم که شاید دوستان با مفاهیم درگیر و پیرامون OOP آشنایی کامل نداشته باشن.

همینطور بنده هم با وجود اینکه با این مفاهیم آشناییت دارم ولی توضیح دادن بدون پیش‌زمینه ای راجب مفاهیم OOP سخت هست.

از طرفی هم نمیتونم بگم که تجربه زیادی دارم حتی با وجود اینکه با Qt یا PySide6 و لایبرری های کاملا OOP محور کار کردم باز فکر میکنم خیلی جا برای یادگیری دارم.

سر همین تو پست بعدی اول به مفاهیم مهم دنیای OOP میپردازم مثل SOLID و همینطور OOP Design Pattern هایی که تو آموزش neetcode یاد گرفتم رو مختصرانه توضیح میدم و سپس نقد رو انجام میدم.

و حال در این مدت چه گذشت.

یادتون بود راجب آموزش PyTorch صحبت کرده بودم که استارتش رو زدم. تقریباً تا ½ اش رو تموم کردم. نزدیک 340 قسمت هست ولی خب بخوام نظرم رو راجب این دوره بگم. اگر میخواید سمت یادگیری عمیق برید. صد در صد اینو پیشنهاد میکنم.

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

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

جدا از اون یک آموزش گیت هم دیدم. از SuperSimpleDev.
نه اینکه گیت بلد نبودم (هر روز rebase و reflog انجام میدم از بس که خرابکاری میکنم و درست میکنم) ولی خب میخواستم که یه مروری بر مفاهیم اولیه بشه و از اونجایی که تو ویدیو سومش به feature branch workflow اشاره میشه سر همین گفتم حتماً ببینمش.

خیلیا git رو یاد میگیرن و ذهنیت گیت ندارن. همش داخل یه برنچ کامیت میکنن و نمیدونن چه وقتی باید برنچ بزنن.
همینطور رفع conflict های PR به صورت لوکال رو هم بخش خیلی جالبی بود که نمیدونستم ممکنه.
اگر گیت بلد نیستید این بهترین آموزش برای شروع هست.

خلاصه از git غفلت نکنید.

آموزش PyTorch تو کانال پین شده هست

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

دلیلش هم این بود که OOP انعطاف بالایی تو طراحی و دیزاین سیستم‌ها میده و این انعطاف میتونه به ضرر افراد کم تجربه تموم بشه.

سر همین قواعدی به وجود اومد به اسم SOLID که کد های OOP باید رعایت کنند. و این قواعد تو بیشتر کد های OOP که امروزه میبینیم جا افتاده.

اسم SOLID کوتاه شده 5 قانون هست که به ترتیب:

1. Single Responsibility Principle
2. Open-Closed Principle
3. Liskov Substitution Principle
4. Interface Segregation Principle
5. Dependency Inversion Principle

Uncle Bob’s SOLID Principles Made Easy 🍀 - In Python!

The SOLID Principles of Object-Oriented Programming Explained in Plain English

کلی ویدیو دیگه با زبان های دیگه هم تو یوتیوب هست که پیشنهاد میکنم ببینید قبل از اینکه پست های پایین رو بخونید.

#OOP
#SOLID

1. Single Responsibility Principle:

هر کلاسی باید تنها یک نقشی رو داشته باشه و یک دلیل برای تغییر داشته باشه.
تشخیص این موضوع همیشه ساده نیست ولی خب با تمرین و خوندن سورس کد متوجه میشید که بقیه چطوری کلاساشون رو جدا میکنن و به مرور زمان جدا میکنید.

چرا اینکارو انجام میدیم؟ اولین فایده‌اش اینه که کدبیسمون ماژولار تر و تمیز تر میشه و امکان تغییر بدون خرابکاری کمتر میشه. که برای یک تیم خیلی مهمه.

دوم اینکه تو سیستم کنترل نسخه مثل گیت راحت‌تر میشه تغییرات رو بررسی کرد. مثلاً میخواید git blame بزنید گیج نمیشید چون که این بخش از برنامه فقط برای یک دلیل و فقط توسط یک نفر تغییر کرده.

ممکنه که همون اول کلاستون یک متد داشته باشه و یکم حرکت عجیب غریبی باشه. ممکنه حتی دیتا هم نداشته باشه. ولی اگر دلیل خوبی داشته باشید میبینید که برنامه تمیز تر و بهتر میشه.

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

#OOP
#SOLID

2. Open-Closed Principle:
اینجاست که abstract class و interface ها معنی پیدا میکنن.
اگر بخوام این دو رو تو یک کلمه خلاصه کنم: قرارداد. (بله فقط مسائل حقوقی رو کم داشتیم که تو برنامه نویسی اضافه شد)

این قانون برای این به وجود اومده که اجازه بده که بدون اینکه کد قدیمیتون رو تغییر بدید برنامتون رو توسعه بدید.
اینطوری احتمال اینکه به باگ بخورید کمتره. به عبارتی Open برای اضافه کردن و Closed برای دستکاری کردن.

بعضی وقتا میبینید که نوع های مختلفی از کلاس دارید که رفتار مشابه دارن ولی تو جزییات تفاوت دارن. تو بخش‌هایی از برنامه هم میتونن جای هم استفاده بشن.
اینجاست که از abstract class یا interface استفاده میکنید تا رفتار های مشترک رو به عنوان یک قرار دادی بسازید که تمام کلاس‌های فرزند ازش پیروی میکنن.

اینطوری اگر خواستید که جایی از هر کدوم از کلاسا به عنوان ورودی استفاده کنید میتونید از کلاس قرارداد (abstract class) یا interface استفاده کنید.

فرق این دو هم تو اینه که abstract class مثل یک کلاس میمونه که میتونی متد های قراردادی که باید پیاده بشن رو بنویسی، همینطور میتونی متد های معمولی هم همراه تعریف داشته باشی که ازش تو کلاس‌های فرزند استفاده بشه.

اما تو interface متد ها بدون تعریف هستن و باید توسط فرزند پیاده‌سازی بشن.
تو هر زبانی ممکنه اسم مفاهیم ها یکم متفاوت باشن. مثلاً تو پایتون یا سی پلاس پلاس interface نداریم.
اما مفاهیم مشابه مثل virtual methods تو ++C و ABC (abstract base classes) و Protocols تو پایتون هستن که برای همین کار ساخته شدن.

#OOP
#SOLID

3. Liskov Substitution Principle:
هر کلاس فرزندی باید بتونه جایگزین کلاس والد بشه و مشکلی برای برنامه پیش نیاد.
این قانون گیج کنندست. و ایرادات اینطوری رو تو کد ها به وضوح نمیشه پیدا کرد.

معمولاً هر وقت که متد های فرزندتون رو override میکنید حواستون باشه که چه منطقی رو پیاده میکنید و اگر احتمال خطا وجود داشت حتماً هندلش کنید.

#OOP
#SOLID

4. Interface Segregation Principle:
بعضی وقتا یه interface یا abstract class کافی نیست.
چون وقتی که interface یا class ات بزرگ و کلی باشه تو کلاس‌های خاص ممکنه متد هایی رو پیاده کنی که اصن برای اون کلاس نیستن.
سر همین بهتره که سلسله ای interface یا abstract class بسازی که کارو ساده‌تر میکنه.

#OOP
#SOLID

5. Dependency Inversion Principle:
کل قاعده Open-Closed برای این بود که بتونیم از کلاس‌های جدید که از کلاس‌های فعلی جدا هستن استفاده کنیم تا برنامه رو بدون تغییر کد قبلی توسعه بدیم.
اما اگر بخوایم اینکارو انجام بدیم باید متد های ما جای اینکه یک کلاس خاصی رو قبول کنن کلاس‌ قرارداد رو قبول میکنن که تضمین میشه کلاس های ورودی حاوی متد های مشخص شده هستن.

اینجا بود که گفتم Liskov Substitution Principle مهمه.
چون آبجکت هایی که قرارداد رو میپذیرن ممکنه که هر جایی که اون کلاس قراردادی رو بپذیره استفاده بشن.
سر همین می‌بینی که این کلاسه یه جا کار میکنه و جای دیگه درست کار نمیکنه.

#OOP
#SOLID

منابع تورنت مشکلات کپی رایت دارن.

اما فکر میکنم برگردوندنشون به کانال اصلی ایده بهتریه.