هر کسی که تجربه خاصی در برنامه نویسی نرم افزار دارد ، با استفاده از پارامترهای قضاوت بر اساس مسیر شغلی خود ، کد نرم افزاری را که دیگران نوشته اند ، قضاوت می کند.
در طول کار حرفه ای خود ، من توسعه دهندگان زیادی را شناخته ام و هزاران کد کد را دیده ام و هنگامی که نیاز به ارزیابی مهارت یک توسعه دهنده دارم ، من به طور عمده به دو عامل نگاه می کنم:
خوشبختانه برخی اصول یا اصول اساسی وجود دارد که بهتر می تواند در کدگذاری بهتر عمل کند.
مخفف 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 -> ادامه دهید
Ercole Palmeri
CMA انگلستان در مورد رفتار Big Tech در بازار هوش مصنوعی هشداری صادر کرده است. آنجا…
فرمان "خانه های سبز" که توسط اتحادیه اروپا برای افزایش بهره وری انرژی ساختمان ها تدوین شده است، روند قانونی خود را با…
گزارش سالانه Casaleggio Associati در مورد تجارت الکترونیک در ایتالیا ارائه شد. گزارشی با عنوان «تجارت هوش مصنوعی: مرزهای تجارت الکترونیک با هوش مصنوعی».…
نتیجه نوآوری مداوم فناوری و تعهد به محیط زیست و رفاه مردم. Bandalux یک چادر Airpure® را ارائه می دهد…
