آرین تاپ لرن

تاریخ انتشار:۱۰:۰ ۱۳۹۸/۹/۲۳

یکی از دغدغه های هر برنامه نویسی نوشتن کدهای تمیز و خوانا با قابلیت نگهداری بالاست. خیلی ها میگن OOP برای این کار به وجود آمده و به کمک OOP میشه به این هدف رسید. اما در محیطی مثل .NET که همه چیز از اول کار با کلاس ها شروع میشه و خارج از دنیای کلاس دنیایی وجود نداره خیلی وقت ها مشاهده میکنیم که شاید جاهایی اصول OOP در حاشیه مونده و کسی از آنها استفاده نمی کنند. و اصولا در شرایطی که باید از این اصول استفاده بشه استفاده صحیح از این اصول مورد توجه نیست.

یکی از این اصول Polymorphism یا چندریختی هست. شما وقتی کلاس هایی داری که ذاتا یکی هستن ولی عملکردهای مختلفی دارن، خوب مسلما باید یک کلاس والد داشته باشی و برای عملکردهای خاص و مختلف ارث بری های مختلف داشته باشید. اجازه بدید با یه مثال ادامه بدیم که موضوع کامل مشخص باشه.

کلاس و کد زیر رو رد نظر بگیرید.

public enum MessageType } ,Success Failure { public class Message } public string MessageText { get; set; } public MessageType Type { get; set; } { class Program } static void Main ( string [ ] args ) } Message msg = new Message ( ) { MessageText= "Success" ,Type =MessageType.Success } ;ShowMessage ( msg ) { private static void ShowMessage ( Message msg ) } switch ( msg.Type ) } :case MessageType.Success ;()ShowGreenMessage ;break :case MessageType.Failure ;()ShowRedMessage ;break :default ;break { { ()private static void ShowGreenMessage } ;()throw new NotImplementedException { ()private static void ShowRedMessage } ;()throw new NotImplementedException { {

در این تکه کد ما کلاسی داریم به اسم Message که میتونه از نوع Success و یا Failure باشه. حالا در برنامه و موقع نمایش تصمیم میگیریم که با توجه به اینکه این کلاس از چه جنسی هست به چه رنگی نمایش داده شود.

اینجا مشکلاتی وجود داره. اولا که هرجا بخایم نمایش داشته باشیم باید تصمیم گیری رو انجام بدیم، شاید بگید که میشه یه تابع تعریف کنیم و اونو صدا بزنیم. اما هنوز یه مشکل دیگه هست. اصل encapsulation که زیر سوال رفته را چه کنیم؟! قسمتی از عملکرد کلاس ما که باید داخل کلاس انجام بشه به بیرون نشت کرده. یه مشکل دیگه هم هست. من وقتی دارم کد شما را review میکنم برام مهم نیست که موقع نمایش پیام چه رنگی را نمایش میدهید. صرفا دانستن اینکه پیام نمایش میدهید برای من کافی است، الباقی ماجرا جزئیاتی است که به شما و کدتان مربوط است. میبینید قابلیت خوانایی هم پایین اومده و با ادامه این روند خوانایی و نگهداری کد پایین و پایین تر می آید.

حالا وقت کمی refactor هست. پس ساختار کلاسمان را به شکل زیر تغییر میدهیم.

class Program } static void Main ( string [ ] args ) } MessageRefactor msg = new SuccessMessage ( ) { MessageText= "Success" } ; ;()msg. ShowMessage { { public abstract class MessageRefactor } public string MessageText { get; set; } ;()public abstract void ShowMessage } public class SuccessMessage : MessageRefactor } ()public override void ShowMessage } ;()ShowGreenMessage { ()private void ShowGreenMessage } ;()throw new NotImplementedException { { public class FailureMessage : MessageRefactor } ()public override void ShowMessage } ;()ShowRedMessage { ()private void ShowRedMessage } ;()throw new NotImplementedException { {

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

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

منبع:nikamooz