a = "salam
print(a)

SyntaxError: unterminated string literal

a = "salam"
if a:
print(a)

IndentationError: expected an indented block after 'if' statement

print(a)
a = 10

NameError: name 'a' is not defined

age = int(input("age: ")) #input: Yasin

ValueError: invalid literal for int() with base 10: 'Yasin'

print("hello" / 3)

TypeError: unsupported operand type(s) for /: 'str' and 'int'

فلسفه معماری MVC (Model-View-Controller) براساس تفکیک مسئولیت‌ها در طراحی و توسعه نرم‌افزار است. در گذشته توسعه و پیاده‌سازی بخش‌های مختلف برنامه نظیر بخش رابطه کاربری، مدیریت داده و بخش کنترل‌کننده در یک فایل پیاده سازی میشد و همین موضوع افزایش پیچیدگی، کاهش مقیاس پذیری و سخت شدن توسعه و ترمیم کدها را به همراه داشت و در نتیجه این موضوع سبب شد تا معماری تحت عنوان MVC ایجاد شود.

معماری MVC در سال 1979 توسط Trygve Reenskaug در مرکز تحقیقاتی Xerox PARC و در حین کار با زبان Smalltalk معرفی شد. هدف این معماری جداسازی منطق کسب‌وکار از رابط کاربری بود تا نرم‌افزارها انعطاف‌پذیرتر و قابل نگهداری‌تر باشند. MVC ابتدا در سیستم‌های گرافیکی Smalltalk برای مدیریت رابط‌های کاربری تعاملی به‌کار رفت و به‌تدریج به یک الگوی اصلی در توسعه نرم‌افزار تبدیل شد.

در دهه 1990، با گسترش برنامه های تحت وب، MVC به‌وسیله فریم‌ورک‌هایی مانند Java Struts و Ruby on Rails وارد دنیای وب شد. این الگو به دلیل تفکیک مسئولیت‌ها و ساختار منظم، محبوبیت بالایی در توسعه برنامه‌های پیچیده یافت. در دهه 2000، فریم‌ورک‌هایی مانند Django، ASP.NET MVC، و Spring MVC این معماری را به‌عنوان هسته طراحی خود پذیرفتند.

با ظهور معماری‌های مدرن مانند MVVM و ابزارهایی مانند React و Angular، مفهوم MVC تغییراتی را تجربه کرد اما همچنان به‌عنوان یکی از بنیادی‌ترین الگوهای معماری در طراحی نرم‌افزار باقی مانده است.

معماری MVC یک الگوی طراحی برای توسعه برنامه‌های وب است (البته هدف اصلی از ایجاد MVC در متن بالا توضیح داده شد). معماری MVC از سه بخش اصلی تشکیل شده است.

◇ بخش اول مدل (Model):
این بخش مسئول مدیریت داده‌ها و منطق کسب‌وکار است. این بخش تمام عملیات مرتبط با ذخیره‌سازی، بازیابی، و پردازش داده‌ها را انجام می‌دهد و با پایگاه داده تعامل دارد. Model مستقل از رابط کاربری است و تنها داده‌های پردازش‌شده را برای View و Controller آماده می‌کند.‌ به عنوان مثال، در یک سیستم رزرو هتل، مدل وظیفه دارد ظرفیت خالی اتاق‌ها را بررسی کند و اطمینان یابد که رزرو جدید برای هتل امکان پذیر است یا خیر. همچنین، اگر رزروی لغو شود، مدل باید ظرفیت را به‌روزرسانی کند. در این سناریو، Model شامل قوانین کسب‌وکار (Business Logic) مانند "هر اتاق فقط یک رزرو می‌تواند داشته باشد" است و این قوانین را هنگام ذخیره یا تغییر داده‌ها اعمال می‌کند.

◇ بخش دوم نما (View):
بخش View مسئول نمایش داده‌ها به کاربر است. این بخش فقط بر نمایش اطلاعات تمرکز دارد و هیچ منطق پردازشی مرتبط با داده‌ها یا منطق کسب‌وکار را شامل نمی‌شود. View داده‌ها را از Model دریافت کرده و به کاربر نمایش می‌دهد.
برای مثال، در یک سیستم فروشگاهی آنلاین، بخش نما می‌تواند صفحه‌ای باشد که لیست محصولات را به کاربر نشان می‌دهد. View فقط از اطلاعات موجود در Model (مانند نام، قیمت، و توضیحات محصول) استفاده می‌کند و آن‌ها را در قالب HTML به نمایش درمی‌آورد. این بخش هیچ‌گونه پردازش روی داده‌ها انجام نمی‌دهد، بلکه فقط آن‌ها را به شکلی قابل فهم و مرتب به کاربر ارائه می‌کند.

◇ بخش سوم کنترل‌کننده (Controller):
بخش Controller وظیفه مدیریت تعاملات کاربر و ارتباط بین Model و View را بر عهده دارد. Controller درخواست‌های کاربر را دریافت کرده و آن‌ها را به Model ارسال می‌کند تا داده‌ها پردازش شوند. سپس، Controller داده‌های پردازش‌شده را به View ارسال کرده تا در رابط کاربری نمایش داده شوند.

معماری Model View Template یا به اختصار MVT به‌طور خاص در فریم‌ورک‌های Django طراحی شده است تا توسعه‌دهندگان را قادر سازد تا کدهای خود را به صورت منظم، خوانا و مقیاس‌پذیر سازماندهی کنند. این معماری مانند MVC از سه بخش اصلی تشکیل شده است که هرکدام وظایف خاصی را انجام می‌دهند. در این معماری بخش View همان بخش Controller در MVC و بخش Template تقریبا نقش View در MVC را دارد.

هنگام استفاده از API در جنگو، بخش Model همچنان مسئول مدیریت داده‌ها و منطق کسب‌وکار است. اما بخش View دیگر داده‌ها را به قالب‌های HTML تبدیل نمی‌کند و به‌جای آن، از Serializer برای ارسال داده‌ها به فرمت‌های JSON یا XML استفاده می‌کند. بخش Template نیز دیگر وجود ندارد.

معماری MVC (Model-View-Controller) یکی از الگوهای طراحی نرم‌افزاری معروف است که به تفکیک منطق کسب‌وکار، رابط کاربری و کنترل تعاملات کمک می‌کند.

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

براساس اصل 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

براساس اصل 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

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

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

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

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...")

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

with open("test.txt", "r") as t:
    t.read()

FileNotFoundError: [Errno 2] No such file or directory: 'test.txt'

import requests

ModuleNotFoundError: No module named 'requests'

names = ["Yasin", "Reza", "Navid"]
print(names[5])

IndexError: list index out of range

names = {'Yasin': '1', 'Reza': '2'}
print(names['3'])

KeyError: '3'

numbers = [1, 2, 3]
print(numbers.sum())

AttributeError: 'list' object has no attribute 'sum'

name = "Yasin"
def get_name():
    print(name)
    name = "ali"

    print(name)

get_name()

UnboundLocalError: cannot access local variable 'name' where it is not associated with a value

unicode_str = b"\u1234\u5678\u90AB"
print(decoded_str.decode("ascii"))

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe1 in position 0: ordinal not in range(128)

result = 5 / 0

ZeroDivisionError: division by zero

large_list = [0] * 1_000_000_000

import os

os.mkdir(r"C:\Windows\System32\new_directory")