SOLID 5 اصل برنامه نویسی شی گرا چیست؟

ارقام هندسی جامد
پرورش
1

SOLID مخفف اختصاری است که به پنج اصل طراحی شی گرا (OOD یا OOP) اشاره دارد. اینها رهنمودهایی است که توسعه دهندگان می توانند با استفاده از آنها نرم افزاری بسازند که مدیریت ، نگهداری و گسترش آن آسان باشد. درک این مفاهیم شما را به توسعه دهنده بهتری تبدیل می کند و به شما کمک می کند تا از مشکلات مدیریت نرم افزار جلوگیری کنید. منظور از یک برنامه نویس خوب چیست؟

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

در طول کار حرفه ای خود ، من توسعه دهندگان زیادی را شناخته ام و هزاران کد کد را دیده ام و هنگامی که نیاز به ارزیابی مهارت یک توسعه دهنده دارم ، من به طور عمده به دو عامل نگاه می کنم:

  • سادگی در خواندن کد ؛
  • چقدر احتمال دارد کد آنها به مرور کار کند و تکامل یابد.

خوشبختانه برخی اصول یا اصول اساسی وجود دارد که بهتر می تواند در کدگذاری بهتر عمل کند.

مخفف SOLID مخفف:
S: اصل مسئولیت منفرد
O: اصل بسته و بسته
L: اصل تعویض لیسکوف
I: اصل تفکیک رابط
D: اصل وارونگی وابستگی ها

بیایید با کاوش در اولین اصل جامد ، یعنی اصل شروع کنیم

اصل مسئولیت منفرد

یک کلاس (یا ماژول) باید فقط یک دلیل برای تغییر ، تکامل داشته باشد.

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

اما چرا؟ 

چرا داشتن فقط یک دلیل برای تغییر بسیار مهم است؟

به عنوان مثال ، اگر دو دلیل متفاوت برای تغییر وجود داشته باشد ، می توان تصور کرد که دو تیم مختلف به دو دلیل مختلف بتوانند روی یک کد کار کنند. هرکدام باید راه حل خود را پیاده سازی کنند ، که در مورد زبان کامپایل شده (مانند C ++ ، C # یا Java) ، می تواند به ماژول هایی منجر شود که با تیم های دیگر یا سایر قسمت های برنامه ناسازگار باشد.

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

شناسایی ویژگی یکی از کلاس ها یا ماژول ها بسیار پیچیده تر از جستجوی چک لیست برای اجرای تست ها است. 

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

چند نمونه از ماژول ها و استفاده از آنها:

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

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

شناسایی نقش ها به جای افراد یا کاربران منطقی تر به نظر می رسد.

بنابراین:

  • کاربر سیستم نرم افزار دلایل تغییر را تعریف می کند.
  • مسئولیت یک خانواده از توابع است که نیازهای یک بازیگر خاص ، یعنی کاربر سیستم را برآورده می کند.
  • بازیگران ، کاربر منبعی برای خانواده برای ویژگیهای عملکردی می شود که باید نیاز کاربر را برآورده کند.
  • تکامل نیازهای کاربر ، راهنمای تکامل عملکرد است.

اصول جامد

بیایید چند نمونه را ببینیم

فرض کنید ما یک کلاس Book داریم که مفهوم کتاب و عملکرد آن را دربرمی گیرد.

کلاس کتاب {

    تابع getTitle () {

        بازگشت "یک کتاب عالی" ؛

    }

    تابع getAuthor () {

        بازگشت "الساندرو باریکو" ؛

    }

    صفحه بعدی تابع () {

        // صفحه بعد

    }

    عملکرد printCurrentPage () {

        echo "محتوای صفحه فعلی"؛

    }

}

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

با این حال ، یک مشکل کوچک وجود دارد. 

با فکر کردن درباره بازیگران درگیر در مدیریت شی کتاب ، چه کسی می توانند باشند؟ 

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

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

به طور خلاصه این کلاس مخلوطی را بین:

  • منطق تجارت با 
  • ارائه 

این می تواند یک مشکل باشد زیرا اصل مسئولیت منفرد (SRP) را نقض می کند. 

چگونه می توانیم تغییر دهیم ، چگونه می توانیم این کد را بهبود بخشیم تا به اصل مسئولیت واحد احترام بگذاریم؟

نگاهی به کد زیر بیندازید:

کلاس کتاب {

    تابع getTitle () {

        بازگشت "Oceano Mare" ؛

    }

    تابع getAuthor () {

        بازگشت "الساندرو باریکو" ؛

    }

    صفحه تبدیل تابع () {

        // صفحه بعد

    }

    تابع getCurrentPage () {

        echo "محتوای صفحه فعلی"؛

    }

}

چاپگر رابط {

    عملکرد چاپ صفحه (صفحه $) ؛

}

کلاس StampaLibro چاپگر را اجرا می کند {

    صفحات عملکرد (صفحه $) {

        echo $ page؛

    }

}

 

class HtmlPrinter پیاده سازی چاپگر {

    صفحات عملکرد (صفحه $) {

        پژواک " صفحه $ " '؛

    }

}

این مثال بسیار ساده نحوه تفکیک ارائه از منطق تجارت را نشان می دهد و مطابق با SRP مزایای زیادی در انعطاف پذیری پروژه ما دارد.

بیایید به یک مثال دیگر نگاه کنیم:

مثالی مشابه مثال بالا ، هنگامی است که یک شی بتواند خودش را از ارائه ذخیره کند و بازیابی کند.

کلاس کتاب {

    تابع getTitle () {

        بازگشت "Oceano Mare" ؛

    }

    تابع getAuthor () {

        بازگشت "الساندرو باریکو" ؛

    }

    صفحه تبدیل تابع () {

        // صفحه بعد

    }

    تابع getCurrentPage () {

        بازگشت "محتوای صفحه فعلی"؛

    }

    ذخیره عملکرد () {

        $ filename = '/ اسناد /'. $ this-> getTitolo (). '-'. $ this-> getAuthor ()؛

        file_put_contents ($ filename، serialize ($ this))؛

    }

}

مانند گذشته ، در اینجا نیز می توانیم بازیگران مختلفی را شناسایی کنیم مدیریت کتاب (به عنوان کتابدار) و ماندگاری. هر زمان که بخواهیم نحوه حرکت خود را از صفحه ای به صفحه دیگر تغییر دهیم ، باید این کلاس را تغییر دهیم. ما می توانیم چندین دلیل برای تغییر داشته باشیم.

کلاس کتاب {

    تابع getTitle () {

        بازگشت "Oceano Mare" ؛

    }

    تابع getAuthor () {

        بازگشت "الساندرو باریکو" ؛

    }

    صفحه تبدیل تابع () {

        // صفحه بعد

    }

    تابع getCurrentPage () {

        بازگشت "محتوای صفحه فعلی"؛

    }

}

کلاس SimpleFilePersistence {

    ذخیره عملکرد (رزرو $ کتاب) {

        $ filename = '/ اسناد /'. $ book-> getTitle (). '-'. $ book-> getAuthor ()؛

        file_put_contents ($ filename، serialize ($ book))؛

    }

}

انتقال عملیات پایداری به کلاس دیگر به وضوح مسئولیت ها را از هم جدا می کند و ما آزاد خواهیم بود که روشهای پایداری را بدون تأثیر بر کلاس کتاب خود مبادله کنیم. به عنوان مثال ، پیاده سازی کلاس DatabasePersistence امری پیش پا افتاده است و منطق کسب و کار ما که حول عملیات کتاب ساخته شده است تغییر نخواهد کرد.

با خواندن اصل دوم Open / Closed -> ادامه دهید

نظر 1

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

ایل TUO ایمیل indirizzo غیر سارا pubblicato. من کمپی سونو obbligatori contrassegnati *

اصل لیسکوف
پرورش
اصل تعویض لیسکوف ، سومین اصل جامد

کلاسهای کودک هرگز نباید تعاریف نوع کلاس والدین را تحت تأثیر قرار دهند یا تغییر دهند. مفهوم این اصل توسط باربارا لیسکوف در سخنرانی اصلی کنفرانس 1987 ارائه شد و متعاقباً در مقاله ای به همراه ژانت وینگ در سال 1994 منتشر شد. تعریف اصلی آنها

روند بازاریابی گوگل
پرورش
نحوه استفاده از Google Trends برای بازاریابی در زمان واقعی

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

استراتژی هوش تجاری
مواد و روش ها
استراتژی هایی برای هوش تجاری موفق

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