برگه تقلب کد تمیز | Clean Code Cheat Sheet

مقدمه نه چندان کوتاه !

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

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

فکر کردم به جای ور رفتن با فریمورک ها و زبان ها کمی رو مهارت های مهندسی نرم افزار کار کنم ، ولی خُب انتخاب مهارت مورد نظر کمی سخت بود ! { بیماری کمالگرایی افراطی }

مثل همیشه دنبال یه نشانه بودم (چقدر اسرارآمیز ! ) ، تا اینکه روزی یکی از دوستان نه چندان نزدیک (فرماندهان ! ) در مورد اهمیت تمیزی و نظافت و تاثیر آن در رستگاری بشر نطق نه چندان کوتاهی برای ما آشخوران داشت ! که خُب کور از خدا چی میخواد ؟ بلطبع تصمیم گرفتم از کتاب Clean Code یا همان کد تمیز نوشته Robert Cecil Martin معروف به عمو Bob شروع کنم ...

قبلتر ها اسم این کتاب رو زیاد شنیده بودم ولی راستش چون اسمش خیلی عجیب غریب نبود ، فکر میکردم کتاب مسخره ایه و سمتش نمیرفتم ! {چقدر ساده لوحانه ! }

برای من شروع این کتاب خیلی هیجان انگیز بود ، همان چیزی بود که من را مجبور میکرد از خواب شیرین بعد از نهار در عصرهای ابری روز جمعه بگذرم !

هر هفته چندین صفحه از این کتاب رو پرینت میزدم ، و با خودم به محل مورد نظر میبردم و مطالعه میکردم ولی چون کتاب نسبتا حجیم بود و ابزار مترجم گوگل یا اَپ دیکشنری در دسترس نبود ، تقریبا یه 6-5 ماهی طول کشید تا 10 فصل ابتدایی آن را بخونم ، چون مطالعه ام به صورت پیوسته نبود ، مطالب به صورت ساختار یافته در ذهنم شکل نگرفت !

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

شروع ..

اگر کمی در اینترنت جستجو کنید با مفاهیم زیادی از قبیل کد تمیز ،کد هوشمند ، کد انسانی ، کد باهوش ، کد کثیف ، کد بد و ... مواجه میشید ، خب اینا چی هستن ؟

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

(البته یه سری هاشون هم مفاهیم انتزاعی / فلسفی هستند که در این مقاله مجالی به پرداختن به آنها نیست ، شاید بعدها درباره این کلمات جالب بیشتر نوشتم !)

خب این حرف ها یعنی چی ؟

لطفا اجازه بدید یک سوال ساده ازتون بپرسم ، کتاب های درسی دوران چهارم ابتدایی خودتون رو لحظه ای تصور کنید ؟ چه چیزی در همه ی آنها مشترک است ؟ محتوا ؟ موضوع ؟ کاربرد ؟

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

پارادایم های برنامه نویسی (procedural , functional , object-oriented .... ) بسته به نوع نرم افزار یا زبان مورد استفاده متغیر هستند مثلا فرض کنید محتوای کتاب ریاضی قطعا با محتوا کتاب علوم متفاوته ولی استانداردی مثل “کد تمیز” هیچ ربطی به نوع زبان برنامه نویسی ، کاربرد اپلیکیشن و... ندارد ! همانظور که فونت ،رنگ فونت ، اندازه فونت و قطع کتاب ریاضی و علوم ، فارسی یکی هست !

امیدوارم این دو را بتوانید تفکیک کنید !

کد تمیز ...

خب رسیدم سر اصل ماجرا ، کد تمیز چی چی هست ؟

خٌب اول به عکس زیر یک نگاه بیاندازید !

به نظرتون کد خط اول و کد خط دوم و سوم برای رایانه ها تفاوتی داره؟

باور کنید هیچ تفاوتی نداره !!!

ولی برای ما انسان ها تفاوت داره !

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

به طور دقیق تر در این کتاب از تعبیر "نویسنده" برای برنامه نویسان استفاده کرده ، همانطور که نویسنده یک کتاب فارغ از صحت مطالب (درست کار کردن کدها ) ، سبک نوشتاری طنز یا علمی (OOP or FP ) باید نوشته ای بنویسید که برای خواننده راحت و درک آن ساده باشد ! (تمیز باشه)

پس دفع بعد که خواستید تکه کدی بنویسید ، به یاد داشته باشید شما نویسنده ای هستید که برای خوانندگانی (انسان هایی) مینوسید که با خواندن کدهای شما ؛ تلاش شما را قضاوت خواهند کرد !

خٌب حالا چطوری با استفاده استاندارد "Clean Code " ، کدهای خواناتر و قابل فهم تری بنویسیم ؟

من این مباحث را در 6 فصل در این نوشته ارائه میدم :

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

1- نام گذاری 2- توابع و متد ها 3- کامنت ها 4- قالب بندی 5- ساختارهای کنترلی (شرطی) 6- شی ها ، کلاس ها / ساختار داده

فصل اول : نام گذاری (انتخاب اسم)

نام ها باید با معنی باشند ؟

قند عسل زیر را در نظر بگیرید !

اگر به شما بگم نام این قند عسل "آبتین" هست ، قطعا ته دلتون میگید عجب آدم بد سلیقه ای بوده باباش که اسمشو قیصر یا فردین نگذاشته !

آیا آبتین اسم قشنگی نیست ؟

به هیچ وجه منظورم این نیست ، منظورم اینه شاید شما اسم های خیلی زیبایی رو زمان برنامه نویسی برای متغیر ها/متدها/کلاس ها و... در نظر میگیرید ولی چون این اسم ها با کاربرد اون متغیر/متد یا کلاس خیلی هم راستا نیستند ، پس شما در حال تولید یک کد کثیف (غیر تمیز ) هستید !

عمدتاً ما در برنامه نویسی برای سه گروه از کدها اسم انتخاب میکنیم :

1- متغیرها(Variables) 2- متدها /توابع (Methods / Functions) 3– کلاس ها(classes)

الف ) قوانین نام گذاری (انتخاب اسم) در متغیر ها :

قانون اول : در نام گذاری متغیرها سعی میکنیم از اسم های (noun) با معنی یا صفت های خیلی کوتاه استفاده کنیم

قانون دوم : زمان انتخاب نام به نوع و ماهیت داده های ذخیره شده در متغیر توجه میکنیم :

الف) اگر داده ها به صورت عدد یا رشته ، شی یا آرایه بودند ، با توجه به مقدار (value) آنها ، متغیر را نام گذاری میکنیم

ب) اگر مقدار(value) یک متغیر مقدار عبارت بولی Boolean(true/false) بود به صورت سوالی با استفاده از is نام گذاری میکنیم ...

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

مثال : برای متغیری که مشخصات مشتری (ایمیل ، نام ، سن ) را ذخیره میکند ، یک نام انتخاب کنید ؟

ب) قوانین نام گذاری (انتخاب اسم) در توابع (متدها) :

قانون اول : در نام گذاری متدها و توابع سعی میکنیم بر اساس عملکردی که تابع دارد یک نام (فعل یا عبارت فعلی ) انتخاب کنیم ، اگر تابع یک مقدار true/false یا همان Boolean را در جواب بازگرداند (return) سعی میکنیم از ساختار is + استفاده کنیم

مثال : تابع چک کردن ساختار ایمیل کاربر را بنویسید ؟

مثال : متدی که عمل ذخیره کردن کاربر در دیتابیس را انجام میدهد را نام گذاری کنید ؟

ج) قوانین نام گذاری (انتخاب اسم) در کلاس ها :

در کلاس ها ؛ به طور کلی با توجه به ماهیت اشیاء ساخته شده در آن ، کلاس به صورت اسم(nouns) و ترجیحا به صورت مفرد نام گذاری می شود .

مثال : کلاسی که اطلاعات کاربران را در برمیگیرد را نام گذاری کنید ؟

نکته تکمیلی : مبحث Case Types یا Name Casing در متغیرها / توابع /متدها و کلاس ها :

به طور کلی ما از چهار مدل (نوع) نام گذاری در برنامه نویسی استفاده میکنیم :

Camel case -> helloWorld

Snake case -> hello_world

Kebab case -> hello-world

Pascal case -> HelloWorld

خُب اینجا یکم سخته تعریف یا استخراج یک قانون واحد ، چون در زبان های مختلف برنامه نویسی بر اساس یه سری قوانین که نمیدونم از کجا و توسط چه کسی تعیین شده! {احتمالا سازنده ی زبان } برنامه نویس ها مدل های مختلفی از چهار مدل بالا را وقت نوشتن اسم ها انتخاب میکنند ، بنظرم بیشتر یه جور قرارداد هست بین برنامه نویس های یک زبان مشخص ، به همین دلیل من فقط به ذکر چند نمونه بسنده میکنم :

مدل Snake case : بیشتر در بین برنامه نویسان پایتون متداول هست که اسم متغیرها و متدها را با علامت _ (آندرلاین ) جدا میکنند :

مثال :

مدل Camel case : این شیوه نوشتاری بیشتر در بین برنامه نویسان جاوا وجاوا اسکریپت برای نوشتن اسم متغیرها و توابع متداول هست

مثال :

مدل Pascal case : معمولا در تمامی زبان های برنامه نویسی کلاس ها را به این شیوه نام گذاری میکنند

مثال :

مدل Kebab case : (بخوانید کباب کیس !) وجه تسمیه این اسم رو نمیدونم ولی فکر کنم از همون کباب ما ایرانی ها (آسیایی ها ) باشه بیشتر در نام گذاری تگ های HTML سفارشی کاربرد دارد ، استفاده از - ( دش ) !

مثال :

نکات تکمیلی در انتخاب اسم (نام گذاری) :

- اسم ها باید بازتاب دهنده منظور نویسنده باشند ، اگر اسمی نیاز به کامنت برای توضیح داشت اون اسم غلط است !

- استفاده از اسم های بسیار مشابه و یا از انتخاب اسمی با غلط املایی باید پرهیز شود !

- نوع متغیر نباید در اسم مشخص باشد مثلا userArray یا userObj نام های اشتباهی هستند !

- سعی کنید از اسم های که راحت تر بشه جستجو کرد استفاده کنید ! (search friendly )

فصل دوم : توابع و متد ها

در نوشتن توابع / متدها ما دوتا قانون خیلی خیلی مهم داریم :

قانون اول : متدها باید تا حد امکان کوچک باشند !

قانون دوم : متدها باز باید کوچکتر باشند !

همناطور که مشاهده میفرمائید ! در نوشتن توابع / متدها مهمترین اصل ما در نوشتن یک تابع این است که تا حد ممکن کوچک باشد و حتی المکان هر تابع / متد فقط یک کار انجام دهد !

نکته : از این جا به بعد فقط کلمه تابع را می آورم ولی یادتون باشه هر جا که گفتم تابع شما متد هم حساب کنید !

البته این کوچکتر بودن هم مربوط به بدنه‌ی تابع میشه (length) و هم حداقل استفاده از پارامتر/آرگومان در توابع که بهتر است بین صفر و حداکثر سه آرگومان استفاده شود !

قانون DRY : یک اصل مهم در توسعه نرم افزار است ، خلاصه این اصل میشه اینکه کدی ننویسید که بیشتر از یک بار نوشته شده باشد ! (پرهیز از کپی / پِست کدها )

وقتی کدی را تکرار میکنیم دو تا اتفاق بدِ خیلی مهم میوفته !

1- برای خطا یابی یا تغیر بخشی از یک کد مجبوریم کلی کد تکراری رو تغیر بدیم (اتلاف وقت و ایجاد باگ )

2- کدها تکراری که برنامه نویسی copy/paste کرده باعث میشه حجم کدها بالا بره و بلطبع حجم برنامه ما بیشتر بشه !

نکته تکمیلی : High levelیا Low level مسئله این است !

در یک دسته بندی خاص به طور کلی ما دو نوع متد داریم ، متدهای که خودمان خلق میکنیم (سطح بالا) و متدهای که از پیش در هسته زبان برنامه نویسی ما موجود هستند ! (سطح پایین)

تا اونجایی که من متوجه شدم ، استفاده از متد سطح پایین از لحاظ تکنیکی به کد تمیز نزدیک تر هستند ولی علمای کد تمیز پیشنهاد میکنند که از متد سطح بالا به خاطر تسلط به نام گذاری و انعطاف پذیری بالاتر استفاده کنیم (یه جورایی حسم میگه در کدتمیز انعطاف پذیری به خلاصه نویسی ارجعیت داره ! )

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

مثال : نوشتن قسمتی از برنامه که ورودی کاربر را برای ایمیل و پسورد چک کند !

در اینجا شاهد یک نمونه کد بسیار تمیز هستید !

نکات تکمیلی در نوشتن توابع :

- بهتر است حتی المکان از ساختار swich/case استفاده نکنید ! چون معمولا بزرگ هستند ، بیشتر از یک کار را انجام میدهند و بیش از چند مسئولیت را بر عهده دارند !

- ایده آل ترین تعداد آرگومان های یک تابع ، صفر است !!! و حداکثر باید 3 عدد باشد .

- هرچند بلوک های try/catch کمی زشت هستند ولی به هر حال بهتر از if های تو در تو هستند !

فصل سوم : کامنت ها

لطفاً ،لطفاً ،لطفاً کد کثیف را کامنت نکنید ! دوباره بنویسید ! چون هیچ چیزی بدتر از یک کامنت که اطلاعات غلط می دهد نیست !

حقیقتاً اگر بخام یکم باهاتون رو راست باشم ، کامنت ها مثل جنایاتی هستن که ما به اجبار مرتکب !

+ جنایتی که عمو باب اینجا گفته یعنی چی ؟

- ببینید ، بخوام یه مثال بزنم ، دیدی مثلا یه نفر میره روی اعصابتون مثلا بهتون بی احترامی میکنه ؟ و شما در اون لحظه دوست دارید تمام دندون های دهنشو یکی یکی در بیارید ؟ حالا یا به دلیل حفظ آبرو و شخصیت یا به این دلیل که مثل من معمولا زورتون نمیرسه بیخیال میشید و با یه لبخند جوکر طور ! میگذرید ، دقیقا استفاده از کامنت یه جور همین لبخند تلخه به کدهای خودمون !

قطعاً اگر زبان های برنامه نویسی رسا و تمیز خلق شده بودند شاید هیچ وقت نیازی به نوشتن کامنت ها نبود !

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

اما چه نوع کامنت های بنویسم :

کلا میشه سه نوع کامنت تمیز نوشت !

اول : کامنت های حقوقی

دوم کامنت های "اخطار"

سوم : کامنت های لیست انجام کار (todo)

به مثال (تصویر) زیر توجه کنید :

نکات تکمیلی در نوشتن کامنت : باید حداکثر منظورتان را با کد برسانید !

فصل چهارم : قالب بندی

اول به تصاویر زیر یه نگاه بیندازید !

خب همنجور که در تصاویر بالا ، در اولین نگاه فارغ از کارکرد کدها چیزی که نظر شما رو جلب کرد ساختار قالب بندی کدها یا همان formatting بود

ما میتونیم با نوشتن کدهای با نظم و انضباط ، افراد را تحت تاثیر قرار بدیم ، به طوری که حتی این نظم باعث بشه ما رو به چشم یه حرفه ای ببیند ! و عکس این قضیه هم صادق هست ، شاید حتی به خاطر نبود نظم و انظباط در ساختار کدهای ما ، ما را به چشم یه برنامه نویس خیلی مبتدی نگاه کنند ، پس خواهش میکنم ، قالب بندی رو جدی بگیرید !

ما در قالب بندی دو ویژگی عمودی و افقی رو در پیش رو داریم

الف) قالب بندی عمودی:

بهتر است طوری ساختار کدهامون رو تنظیم کنیم که حداقل تکان در قسمت سر و چشم باشد .

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

ب) قالب بندی افقی :

سعی کنید تا میتونید به سمت راست پیمایش نکنید ! هرچند میشه فونت را کمی کوچکتر کرد و یا از مانیتور بزرگ استفاده کرد ولی خب این کار اساساً غلط است ، و حداکثر طول هر خط کد نباید بیشتر از 120 کاراکتر باشد .

نکته مهم : در تیم های برنامه نویسی ، قوانین داخلی یک تیم در مبحث قالب بندی ارجحیت دارند به سایر قوانین ، اصولاً بهتر است در تیم های برنامه نویسی IDE ها ، به یک شکل برای قالب بندی تنظیم شوند .

من در بحث قالبندی مدیون سازنده پلاگین Prettier هستم !

فصل پنجم : ساختارهای کنترلی (شرطی)

اول بگم که توی مبحث ساختار های شرطی یا همان کنترلی اولویت ما همیشه استفاده از if هست تا دیگر ساختار های مثل switch/case !

ولی خب توی همین if ها هم یه سری نکات ظریف وجود داره که در ادامه بهشون میپردازم

استفاده از نگهبان ! (Guard Clauses)

در برنامه نویسی ، نگهبان عبارتی بولی (boolean expression) است که اگر اجرای برنامه در شاخه مورد نظر ادامه یابد ، باید صحت را ارزیابی کند. صرف نظر از اینکه از کدام زبان برنامه نویسی استفاده میکنید ، کد محافظ(guard code) یا بند محافظ (guard clause) بررسی پیش شرط یکپارچگی است که برای جلوگیری از بروز خطا در هنگام اجرای کد استفاده می شود. " ویکی پدیا

فرض کنید نگهبان کاخ سلطنتی ملکه بریتانیا هستید ، شما با چشمان تیز بین خود دنبال افراد مشکوک هستید یا دنبال افراد سالم ؟ (سوال دارای ابعاد نامحسوسی می باشد !)

نگهبان (guard) چی هستند ؟ به زبان ساده (آدمیزادی ! ) تکه کدهای که ما می نویسیم تا ورودی کاربران یا سطح دسترسی آنها رو چک کنند و اگر با اطلاعات صحیح مغایرت داشتند سریعا واکنش نشان دهند

حالا در نوشتن نگهبان لحاظ کردن دو تا نکته خیلی ضروری است

اول : اینکه در مبحث کد تمیز باید از تکه کدهای نگهبانی استفاده کنیم که " آنچه را که غلط است چک کند نه آن چه را که صحیح است ! " ( نگران نباشید توی مثال متوجه منظورم میشید )

دوم اینکه در بدنه ی گارد ها ، باید از ساختار شکست سریع (fail fast ) استفاده شود .

برای روشن تر شدن موضوع به تصویر زیر توجه کنید

نکته تکمیلی : برای مدیریت خطا ها مخصوصا در جاوا اکسکریپت و حتی المکان در سایر زبان ها بهتر است از ساختار try/catch استفاده شود .

نکته : مباحث بالا بیشتر در حیطه همزمانی (Concurrency) هستن !

فصل ششم : شیء ها ، کلاس ها / ساختار داده

خُب قبل از اینکه وارد بحث بشم میخام قبلش تفاوت دوتا موضوع رو براتون مشخص کنم تا دچار اشتباه نشوید ، ما در برنامه نویسی یه سری اصول داریم که معمولا در معماری نرم افزار ها از آن استفاده میشود مثل اصل SOLID , KISS ,DRY این اصول بیشتر تاکید بر انعطاف پذیری و قابلیت نگه داری دارند ، ولی ما در "کد تمیز" تمرکز اصلی را روی حداکثر خوانایی داریم ولی در جایی که بین خوانایی و و انعطاف پذیری قرار باشه انتخاب کنیم ، خوانایی را قربانی میکنیم ! (خیلی به ندرت پیش میاد این موضوع )

پس میشه از این اصول مخصوصا اصل SOLID که اتفاقا توسط نویسنده کتاب کد تمیز آقای رابرت سی مارتین در سال 2000 معرفی شد ، در تمیز کردن کد ها استفاده کنیم !

نکته : ما در کد تمیز فقط با اصل اول و دوم SOLID یعنی قانون SRP و قانون OCP کار داریم !

خُب حالا بریم سراغ ادامه ماجرا ؛ شیء و کلاس ها !

به صورت "کاملا شخصی" بنده مبحث اجرای کد تمیز را در کلاس ها و شیءگرایی به اجرای 5 قانون محدود کردم !

قانون اول : کلاس ها تا جای ممکن باید کوچک باشند !

خٌب این قانون فکر نکنم توضیح خاصی نیاز داشته باشه !

قانون دوم : کلاس ها باید حداقل وابستگی را به هم داشته باشند

این اصل از اساس قانونِ دمیتر یا قاعده حداقلِ دانش الهام گرفته شده است بر اساس این قانون

الف) هر واحد(کلاس) باید اطلاعی اندک از سایر واحدها داشته باشد؛ البته تنها از واحدهایی که دارای رابطه «نزدیک» با این واحد دارند،

ب) هر واحد تنها باید با دوستانش حرف بزند؛ از غریبه‌ها دوری کند

برای جا افتادن این قانون این مثال جالبه !
مثال : فرض کنید شما یک اسب خیلی قشنگ و زیبا دارید ، خٌب حالا قصد دارید به اسب فرمان حرکت بدهید ،
آیا شما به چهار تا پای اسب به صورت تک به تک فرمان حرکت میدهید یا به اسب ؟

تقلب : زمانی که در برنامه نویسی از تعداد نقطه های بالا استفاده کردید بدونید ، این قانون رو زیر پا گذاشتید !!

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

قانون سوم : هر کلاس فقط باید یک وظیفه داشته باشد

خُب این قانون از S اصل SOLID یعنی اصل یگانگی مسئولیت گرفته شده ، بر اساس این قانون ما باید به هر کلاس یک وظیفه بدیم ، مثلا کلاسی که مربوط به احراز هویت کاربران (Auth) هست اگر دربردارنده ی متدهای ورود و ثبت نام کاربران باشد قابل قبول ولی اگر دارای متد نمایش دهنده مطالب کاربران باشد یک کلاس غیر تمیز محسوب میشود !

در کل با در نظر گرفتن این قانون برنامه نویسان قادر نخواهند بود کلاس های همه فن حریف بنویسند !

قانون چهارم : یک کلاس باید نسبت به توسعه باز و نسبت به اصلاح بسته باشد !

خُب این قانون از O اصل SOLID یعنی اصل باز ـ بسته گرفته شده ، بر اساس این قانون به طور خلاصه باید در کلاس ها زمانی که میخواهیم قابلیت جدیدی اضافه کنیم اون قابلیت مثل یک افزونه به کلاس اضافه شود و نیاز نباشد کدهای دیگه بازنویسی شوند ولی زمانی که بخواهیم ویژگی یک کلاس را ویرایش کنیم از هفت خوان رستم بگذریم !

تقلب : معمولا این اصل را با کمک ارث بری یا چندریختی عملی میکنیم !

قانون پنجم :کلاس ها باید انسجام بالایی داشته باشند !

انسجام(Cohesion) بیانگر واضح، آشکار و مشخص بودن مسئولیت ها و وظایف یک کلاس است !

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

تقلب : زمانی که در یه کلاس ویژگی (property) یا متدی بلا استفاده مونده ، بفهمید انسجام کلاستون مشکل داره !

نقدی بر این نوشته !

خُب قبل از خداحافظی حتما یه نکته رو بگم ، نقدی که ممکنه بر نوشته من وارد باشه اینه که :

1- به دلیل سهل انگاری و طولانی شدن زمان خواندن این کتاب نکته مهمی از زیر دستم در رفته باشه !

2- یه جایی یه مطلب مهمی رو دیده باشم به دلیل اینکه اون مطلب رو پیش پا افتاده تصور کردم ازش صرف نظر کرده باشم در صورتی که ممکنه اون نکته برای شما حیاتی باشه , و بلعکس !

خلاصه تنبل نباشید و این کتاب را خودتون یه بار بخونید :)

شاید نوشته زیر هم برای شما مفید باشه !

ساختار داده ها و الگوریتم ها به زبان آدمیزاد !

قطعا نظرات شما مایه‌ی مفاخرت و مباهات اینجانب می باشد :)