جستجو برای:
سبد خرید 0
  • مطالب
  • تالار گفتگو
  • نمونه کارها
  • درباره ما
  • دوره آموزشیجدید
    • Css
    • تست در برنامه های دات نت
    • آشنایی با Canvas
  • تماس با ما
SarezCodes - سعید رضایی

ورود

گذرواژه خود را فراموش کرده اید؟

ثبت نام

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

SarezCodes - سعید رضایی
  • مطالب
  • تالار گفتگو
  • نمونه کارها
  • درباره ما
  • دوره آموزشیجدید
    • Css
    • تست در برنامه های دات نت
    • آشنایی با Canvas
  • تماس با ما
ورود
0

وبلاگ

SarezCodes - سعید رضاییمحتوادوره آموزشیاصول طراحیاصول طراحی SOLID در #C (قسمت سوم)

اصول طراحی SOLID در #C (قسمت سوم)

17 فروردین 1401
ارسال شده توسط سعید رضایی
اصول طراحی، برنامه نویسی
203 بازدید
زمان مطالعه: 4 دقیقه

در این مطلب میخواهیم در مورد اصل سوم SOLID یعنی Liskov Substitution Principle صحبت کنیم

Liskov Substitution Principle

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

این اصل پیشنهاد می کند که کلاس های مشتق شده خود را به گونه ای بنویسید که هر کلاس فرزند (کلاس مشتق شده) باید کاملاً به جای کلاس والد خود (کلاس پایه) ،بدون تغییر رفتار  قابل تعویض باشد.

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

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

public class ReadParameters
{
    public virtual string GetDbConnString()
    {
        string dbConn = "Connection String From JSON File";
        //Read json setting file to get Connection String
        dbConn = ParseServerDetails(dbConn);
        return dbConn;
    }

    public string ParseServerDetails(string DbConn)
    {
        return DbConn + " - Parsed";
    }
} 

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

public class ReadParametersFromXML : ReadParameters
{
    public override string GetDbConnString()
    {
        string dbConn = "Connection String From XML File";
        //Read XML file to get Connection String
        dbConn = ParseServerDetails(dbConn);
        return dbConn;
    }
} 

اکنون به کد زیر نگاه کنید که در آن شیء کلاس پایه (ReadParameters) را نمونه سازی کرده ایم و سپس آن را با شیء کلاس مشتق شده (ReadParametersFromXML) جایگزین کرده ایم تا رشته اتصال پایگاه داده را از فایل بخوانیم.

 class Program
{
    static void Main(string[] args)
    {
        ReadParameters readParameters = new ReadParameters();
        Console.WriteLine(readParameters.GetDbConnString());

        readParameters = new ReadParametersFromXML();
        Console.WriteLine(readParameters.GetDbConnString());

        Console.ReadKey();
    }
}

با اجرای کد بالا خروجی های زیر را دریافت می کنیم :

Connection String From JSON File - Parsed

Connection String From XML File - Parsed

از خروجی بالا می بینیم که اگر کلاس پایه را با کلاس مشتق شده جایگزین کنیم، رشته اتصال پایگاه داده را به جای فایل JSON مانند کلاس پایه، از فایل XML برمی گرداند. اکنون اگر ورودی های رشته اتصال پایگاه داده در فایل JSON و XML متفاوت باشد، این جایگزینی می تواند رفتار را تغییر دهد. این نقض اصل جایگزینی لیسکوف در اصول SOLID است.

اکنون مشکل را به صورت زیر حل میکنیم :

public abstract class ReadParameters
{
    public abstract string GetDbConnString();

    public string ParseServerDetails(string DbConn)
    {
        return DbConn + " - Parsed";
    }
}

public class ReadParametersFromXML : ReadParameters
{
    public override string GetDbConnString()
    {
        string dbConn = "Connection String From XML File";
        //Read XML file to get Connection String
        dbConn = ParseServerDetails(dbConn);
        return dbConn;
    }
}

public class ReadParametersFromJSON : ReadParameters
{
    public override string GetDbConnString()
    {
        string dbConn = "Connection String From JSON File";
        //Read XML file to get Connection String
        dbConn = ParseServerDetails(dbConn);
        return dbConn;
    }
} 

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

 static void Main(string[] args)
 {
    ReadParameters readParameters = new ReadParametersFromXML();
    Console.WriteLine(readParameters.GetDbConnString());

    readParameters = new ReadParametersFromJSON();
    Console.WriteLine(readParameters.GetDbConnString());

    Console.ReadKey();
 }

پس از اجرای برنامه فوق، خروجی را مطابق زیر دریافت می کنیم

Connection String From XML File - Parsed

Connection String From JSON File - Parsed

بنابراین ما پیاده سازی را مطابق اصل جایگزینی Liskov در اصول SOLID با انتزاعی کردن کلاس پایه و تعریف تابع GetDbConnString به صورت abstract تصحیح کردیم.

مزایا

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

سخن پایانی

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

همچنین، هیچ ابزاری برای اطمینان از این اصل کمک نمی‌کند و شما باید بررسی‌های دستی ، بازبینی کد یا آزمایش کد را انجام دهید تا مطمئن شوید که کد، اصل جایگزینی Liskov در اصول SOLID را نقض نمی‌کند.

Print Friendly, PDF & Email
برچسب ها: OOPSOLIDشی گرایی
قبلی اصول طراحی SOLID در #C (قسمت دوم)
بعدی اصول طراحی SOLID در #C (قسمت چهارم)

دیدگاهتان را بنویسید لغو پاسخ

جستجو برای:
برچسب‌ها
#C (3) css (12) css in depth (12) OOP (4) SOLID (5) unit test (4) آزمایش واحد (4) آزمون واحد (6) آموزشCSS (11) آموزش پایه ای (12) بازی ریاضی (4) بازی نویسی (2) برنامه نویسی (13) تست (5) توسعه آزمون محور (3) دات نت (1) ریاضی بازی (4) ریاضی در بازی (4) زبان برنامه نویسی (9) سی شارپ (3) شی گرایی (4) فناوری اطلاعات (3)
دسته‌ها
  • #C (6)
  • Css (13)
  • اصول طراحی (5)
  • بازی سازی (4)
  • بدون دسته بندی (3)
  • برنامه نویسی (20)
  • تست (7)
  • تست در برنامه های دات نت (6)
  • جاوا اسکریپت (1)
  • دوره آموزشی (19)
  • فناوری اطلاعات (5)
  • نگاه عمیق به سی شارپ (1)
نوشته‌های تازه
  • اصول طراحی SOLID در #C (قسمت آخر) 17 فروردین 1401
  • اصول طراحی SOLID در #C (قسمت چهارم) 17 فروردین 1401
  • اصول طراحی SOLID در #C (قسمت سوم) 17 فروردین 1401
  • اصول طراحی SOLID در #C (قسمت دوم) 17 فروردین 1401
  • اصول طراحی SOLID در #C (قسمت اول) 17 فروردین 1401
  • محبوب
  • جدید
  • دیدگاه ها
پشتیبانی

ما موضوع Sarez را نامگذاری کردیم، زیرا برای ما بهترین علامت های تجاری ساده هستند. رشد  برند ها در توانایی آنها درک می شود.

    2022© سارز کد SarezCodes
    اشتراک گذاری در شبکه های اجتماعی
    ارسال به ایمیل
    https://sarezcodes.ir/?p=2772
    • دسته بندی دوره ها
    • دوره های من
    • جستجو

    دسته بندی دوره ها

    دوره های من

    برای مشاهده خریدهای خود باید وارد حساب کاربری خود شوید

    جستجو

    مرورگر شما از HTML5 پشتیبانی نمی کند.