| کانال توسعه‌دهندگان پایتون |
6.61K subscribers
38 photos
2 videos
4 files
43 links
⭕️ کانال توسعه‌دهندگان پایتون دولوپیکس

💠 دولوپیکس | جامعه توسعه‌دهندگان ایرانی

💎 @Developix
🚀 Developix.ir

📌 پشتیبانی و تبلیغات:
@DevelopixSupport
Download Telegram
🔶 بخش اول
🔶 مفاهیم شی‌گرائی

🔻 اصول SOLID
اصول SOLID پنج قاعده مهم در طراحی و توسعه نرم‌افزار هستند که به نوشتن کدی تمیز، انعطاف‌پذیر و قابل نگهداری کمک می‌کنند. این اصول ابتدا توسط Robert C. Martin (عمو باب) مطرح، و برای کاهش وابستگی‌ها و افزایش قابلیت گسترش کد طراحی شده‌اند.


🔻 اصل‌ تک مسئولیتی (SRP)
براساس اصل Single Responsibility Principle، هر کلاس باید فقط یک مسئولیت داشته باشد و تنها یک دلیل برای تغییر آن وجود داشته باشد. برای مثال، یک کلاس نباید هم وظیفه مدیریت کاربران و هم ارسال ایمیل را برعهده داشته باشد.


✖️ مشکل: کلاس زیر هم وظیفه مدیریت کاربر و هم ارسال ایمیل ایمیل را برعهده دارد:
class UserManager:
def register_user(self, user_data):
pass

def send_email(self, email):
pass


✔️ راه‌حل: تفکیک وظايف:
class UserManager:
def register_user(self, user_data):
pass

class EmailService:
def send_email(self, email):
pass



🔻 اصل باز/بسته (OCP)
براساس اصل Open/Closed Principle، کلاس‌ها باید برای گسترش باز و برای تغییر بسته باشند. برای مثال، اگر نیاز به اضافه کردن نوع جدیدی از گزارش دارید، به جای تغییر کلاس اصلی، از وراثت یا پلی‌مورفیسم استفاده کنید.


✖️ مشکل: کلاس زیر مسئول چندین نوع پرداخت است:
class PaymentProcessor:
def process_payment(self, payment_type):
if payment_type == "CreditCard":
pass
elif payment_type == "PayPal":
pass


✔️ راه‌حل: جداسازی روش‌های پرداخت:
from abc import ABC, abstractmethod

class Payment(ABC):
@abstractmethod
def process(self):
pass

class CreditCardPayment(Payment):
def process(self):
pass

class PayPalPayment(Payment):
def process(self):
pass



🔻 اصل جایگزینی لیسکوف (LSP)
براساس اصل Liskov Substitution Principle، زیرکلاس‌ها باید بتوانند بدون تغییر رفتار برنامه، جایگزین کلاس‌های پدر شوند. برای مثال، یک مربع (Square) نباید به‌عنوان زیرکلاس یک مستطیل (Rectangle) تعریف شود، اگر رفتارهای مستطیل را نقض کند.


✖️ مشکل: فرض کنید کلاسی به نام Bird داریم که برای پرنده‌ها طراحی شده است و دو زیرکلاس داریم: Sparrow (گنجشک) و Penguin (پنگوئن). در این مثال، متد fly() برای پنگوئن اشتباه است، زیرا پنگوئن نمی‌تواند پرواز کند.
class Bird:
def fly(self):
pass

class Sparrow(Bird):
def fly(self):
pass

class Penguin(Bird):
def fly(self):
return NotImplemented

sparrow = Sparrow()
sparrow.fly() # Output: is ok

penguin = Penguin()
penguin.fly() # Output: Not Implemented


✔️ راه‌حل: تفکیک رفتارها
class Bird:
def lay_eggs(self):
pass

class FlyingBird(Bird):
def fly(self):
pass

class Sparrow(FlyingBird):
...

class Penguin(Bird):
def swim(self):
pass



🔻 اصل جداسازی اینترفیس (ISP)
براساس اصل Interface Segregation Principle، کلاس‌ها نباید مجبور شوند متدهایی را پیاده‌سازی کنند که به آن‌ها نیازی ندارند. برای مثال، اگر یک اینترفیس شامل متدهای کار و غذا خوردن باشد، یک ربات که نمی‌تواند غذا بخورد، نباید مجبور به پیاده‌سازی متد غذا خوردن شود.


✖️ مشکل: کلاس Printer مجبور است متد scan را پیاده‌سازی کند، حتی اگر این عملیات مورد نیاز نباشد.
class Machine:
def print(self):
pass

def scan(self):
pass

class Printer(Machine):
def print(self):
pass

def scan(self):
raise NotImplemented


✔️ راه‌حل: در اینجا رابط‌ها جدا می‌شوند تا هر کلاس فقط متدهای مورد نیاز خود را پیاده‌سازی کند:
class Printer:
def print(self):
pass

class Scanner:
def scan(self):
pass

class PrinterDevice(Printer):
def print(self):
print("Printing...")

class SimpleScanner(Scanner):
def scan(self):
print("Scanning...")



🔻 اصل وارونگی وابستگی (DIP)
براساس اصل Dependency Inversion Principle، ماژول‌های سطح بالا نباید به ماژول‌های سطح پایین وابسته باشند. هر دو باید به انتزاعات وابسته باشند. برای مثال، یک کلاس نباید مستقیماً به دیتابیس خاصی وابسته باشد. به جای آن باید از اینترفیس یا انتزاعی برای ارتباط استفاده کند.


🔖 #Python, #پایتون, #شئ‌گرایی, #OOP, #SOLID

👤 ȺʍìɾⱮօհąʍʍąժ

💎 Channel: @DevelopixPython
👍14🔥41