درک مفهوم کدنویسی تمیز در اندروید
تصور کنید شما در جستجوی یک کتاب هستید و به همین منظور به یک کتابخانه رفته اید. اگر آن کتابخانه کتابهای خود را دسته بندی کرده باشد، طبیعتا شما سریعتر می توانید به کتاب مورد نظر خود برسید. اگر این کتابخانه علاوه بر دسته بندی، معماری و طراحی داخلی زیبایی نیز داشته باشد، شما احساس راحتی و رضایت خواهید داشت.
این مثال را بیان کردم تا این مطلب را برسانم که مشابه همین وضع را در کدنویسی نیز داریم. اگر شما در یک تیم کار می کنید، کدهای شما باید به حدی تمیز نوشته شده باشد که هم تیمی های شما تنها با خواندن اسم متغیرها یا پکیج ها یا کلاسها، متوجه کد شما بشوند و دیگر نیازی به از صفر کد زدن نباشد .
کد تمیز چیست؟
کد شما زمانی مفهوم تمیز بودن را دارد که توسط بقیه اعضای تیم قابل خواندن باشد. اشتباه نکنید، منظور ما از راحت خواندن، فقط خواندن روزنامه وار نیست بلکه آن خواندن باید همراه با فهم درست از کد شما باشد و فرقی ندارد که خواننده کد شما از اعضای تیم شماست یا یک توسعه دهنده دیگر.
به همراه فهم درست از کد، قابل خواندن بودن، تغییرپذیر بودن، انعطاف پذیر بودن و قابل نگهداری بودن می آید.
خصوصیات یک کد تمیز
- کد شما باید زیبا باشد: کد شما باید همان لبخندی را به وجود بیاورد که یک موزیک خوش ساخت یا یک ماشین زیبا به وجود می آورد.
- کد شما باید مورد مراقبت قرار گرفته باشد: “افرادی زمانی را صرف ساده سازی و مرتب سازی این کد کرده اند و دقت خوبی را نسبت به جزییات داشتند” کد شما باید همچین طرز تفکری را القا کند.
- کد شما باید متمرکز شده نیز باشد: هر کدام از متدهای شما، کلاسها شما و یا ماژول های شما باید طوری نوشته شده باشد که با توجه به جزییات زیاد اطراف، کاملا متمرکز باشد و توط کدها یا کلاس های دیگر قابل دستکاری نباشد.
- هیچ دوباره کاری ایی نداشته باشد.
- توانایی اجرای همه تست ها را داشته باشد.
- سعی کنید تا حد امکان، تعداد کلاس ها، متدها، متغیر ها و … را پایین نگه دارید.
اسامی با معنی انتخاب کنید
انتخاب یک اسم خوب ممکن است زمان بر باشد اما بعدا زمان از دست رفته را جبران می کند. اسم یک متغیر، کلاس یا متد باید به تمامی سوالات پاسخ بدهد. چرا وجود دارد؟ چه کاری انجام می دهد؟ چطور استفاده می شود؟ و …. اسمی که انتخاب می کنید باید به درستی به تمامی این سوالات پاسخ بدهد در غیر اینصورت حتما نیازمند comment می باشد.
اسامی کلاس ها
اسامی کلاس ها باید اسم یا یک عبارت اسمی باشد. اسمی مانند Customer، WikiPage، Account و AddressParser و …. اینها می توانند اسامی مناسبی باشند اما اسامی ایی مانند Manager، Processs، Data و …. مناسب نیستند اگرچه یک اسم هستند اما به طور واضح بیان نمی کنند که این کلاس چه وظیفه ایی دارد. اسم کلاس ها نباید فعل باشد.
اسامی متد ها
اسامی متد ها باید یک فعل یا یک عبارت فعلی باشند مانند postPayment، deletePage و…. . متدهایی مانند Accessor ها و mutators ها و predicate ها باید با پیشوند هایی مانند get و set نامگذاری بشوند.
حال درباره قوانین S.O.L.I.D درباره نوشتن کدهای تمیز صحبت می کنیم.
قوانین S.O.L.I.D توسط رابرت مارتین (عمو باب ) به وجود آمده است و شما را در نوشتن یک کد تمیز راهنمایی می کند.
Single Responsibility Principle – SRP
این قانون بیان می کند که در کد شما، هر کلاس باید یک وظیفه را داشته باشد، شما میتوانید هر چه را که خواستید به کلاس اضافه کنید یا از آن کم کنید اما در این کار باید وجود ندارد و بر طبق وظیفه آن کلاس باید انجام بشود. سعی کنید کلاس های بزرگ را به کلاس های کوچکتر تقسیم کنید و از کلاسها بزرگ یا God Class دوری کنید.
Open-Closed Principle – OCP
این قانون به این معناست که کدهای شما و کلاس های شما باید برای ارث بری باز باشند اما برای تغییر، بسته باشند. برای مثال اگر شما یک کلاس به نام A دارید و یکی از هم تیمی های شما می خواهد در یک متد در کلاس A تغییری ایجاد کنید، باید بتواند به راحتی از کلاس A ارث بری کند و تغییرات خود را اعمال کند اما نتواند مستقما و در درون کلاس A تغییری ایجاد کند.
Liskov Substitution Principle – LSP
این قانون بیان می کند که زمانی که یک کلاس فرزند از کلاس پدر خود ارث بری می کند و یم کتد را برای override فرا می خواند، این کار نباید باعث بشود که عملکرد کلاس پدر از بین برود.
Interface Segregation Principle – ISP
بگذارید این قانون را با یک مثال توضیح بدهیم. فرض کنید یک کلاس به نام کلاس A دارید و میخواهید این کلاس را در کلاس B پیاده سازی (Implement) کنید و برای این کار لازم نیست تمامی متدهای کلاس A در درون کلاس B پیاده شوند . درواقع نباید هیچ کلاسی را مجبور به override کردن تمامی متد های یک Interface کرد.
Dependency Inversion Principle – DIP
تعریف عمو باب از قانون بالا دو نکته مهم دارد:
- ماژول های سطح بالا نباید به ماژول های سطح پایین وابسته باشند بلکه هر دو باید به Abstraction ها وابسته باشند.
- Abstraction ها نباید به جزییات وابسته باشند بلکه جزییات باید به Abstraction ها وابسته باشند.
ماژول های سطح بالا که منطق های پیچیده را پیاده سازی می کنند، باید به سادگی قابل استفاده دوباره و همچنین تاثیرناپذیر از ماژول های سطح پایین باشند. برای رسیدن به این هدف، باید یک Abstraction ایجاد کنید و بوسیله آن، ماژول های سطح پایین و سطح بالا را از یکدیگر تفکیک کنید.
این پنچ مورد، قوانین بسیارمهمی در مبحث کدنویسی تمیز بودند و حتما سعی کنید در پروژه های خود از این قوانین استفاده کنید تا هم شما و هم هم تیمی های شما از کد نوشته شده راضی باشند.
دیدگاهتان را بنویسید
برای نوشتن دیدگاه باید وارد بشوید.