آخرین پست من در یادداشت به پایان رسید، که فایل های کد نیاز به یک ساختار قابل اعتماد دارند. کار مولدتر و لذت بخش تر می شود اگر بدانید که کجا چیست، بدون اینکه برای خواندن یک کاراکتر خسته شوید – فقط با اسکن خطوط. و حتی لازم نیست ترتیب بخش‌ها را حفظ کنید، اگر ساختار فایل به یک قانون کلی پایبند باشد: از کلی تا جزئیات. این قانون بصری است و از شما برای درک کد در یک خواندن پشتیبانی می کند. بذار توضیح بدم
حتی ژاپنی ها یا یهودیان شروع به خواندن یک فایل کد در گوشه سمت چپ بالا می کنند. در آن مرحله آنها ممکن است – یا نه – اطلاعاتی از محتوا داشته باشند. پس بهتر است هنگام شروع خواندن، تصویری وسیع از مطالب به صراحت بدست آورید. بعداً جزئیات کوچکتر و کوچکتر در صورت لزوم اضافه می شود – از کلی تا جزئیات.
عمومی ترین آنها متا اطلاعات هستند، مانند نویسنده، تاریخ و مجوز. به نظر من مجوز متن بسیار زیادی برای گنجاندن در یک فایل کد است. فقط یک مرجع به فایل وارد کنید یا فایل را در مکانی مورد انتظار مانند دایرکتوری ریشه پروژه ها قرار دهید که از نظر قانونی نیز الزام آور است. و سایر اطلاعات متا از جمله قالب بندی آن را به حداقل برسانید، زیرا به ندرت مورد توجه است. اما آن را در بالا یا پایین قرار دهید تا به راحتی از آن بگذرید.
اغلب در هدر متا یک یا چند خط می بینید که محتوا یا هدف فایل را خلاصه می کند. نردبان بسیار مهمتر است و باید درست بالای نام فضای نام / بسته / شی قرار گیرد، بنابراین هر دو واحدی بسازید که جهت گیری و انتظارات شما را تنظیم کند. این بخشی بسیار مهم است و ارزش صرف زمان برای آن را دارد. این به نویسنده کمک می کند تا درک خود را از آنچه در اینجا باید به دست آورد، واضح تر کند، که می تواند به طور چشمگیری وضوح کد و در نتیجه کیفیت را بهبود بخشد. همچنین تضمین می‌کند که نام فضای نام / بسته / نام شیء، خلاصه‌ای رسا و تکان دهنده از خلاصه است. یافتن چنین نام هایی بخش خوبی از برنامه نویسی حرفه ای است و این ترتیب شما را در آن پشتیبانی می کند. زیرا اگر احساس می کنید که معنایی در نام وجود ندارد، باید آن را در خلاصه اضافه کنید. فقط در اینجا متوقف نشوید، اما خوب فکر کنید که چه چیزی در مورد خلاصه می تواند با انتخاب یک نام بهتر حذف شود. این تکنیک را می توان برای هر شناسه ای نیز اعمال کرد.
اطلاعات کمتر کلی بعدی، شماره نسخه این فضای نام و زبان مورد استفاده است. موارد بعدی پراگماها (ویژگی های زبان اختیاری) و کتابخانه هایی هستند که در اینجا استفاده می شوند. اول آنهایی که از هسته زبان هستند، بعد از آنهایی که شخص ثالث در نهایت آنهایی که داخلی هستند. ثابت های سراسری، تعداد و متغیرها به شرح زیر هستند. اگر همه این موارد بیش از چند مورد هستند – برای نظارت بهتر آنها را گروه بندی کنید. اکنون ما فقط روال ها، توابع یا روش ها را داریم. جداکننده های بصری برای تمایز بین بخش سر که به تازگی توضیح داده شده و انواع مختلف روش ها مفید هستند. پاراگراف‌های زیر فقط در مورد روش‌ها هستند، زیرا اگر فقط توابع داشته باشید، می‌توانید بدون تفکر عمیق‌تر آنها را بر اساس موضوع گروه‌بندی کنید. اما باید برخی از اصولی را که به بهترین وجه در زمینه شی گرا تدریس می شوند نیز اعمال کنید.
منطقی است که با سازنده شروع کنیم. نه تنها به این دلیل که اولین روشی است که شما استفاده خواهید کرد و احتمالاً اولین روشی است که خواننده به دنبال آن خواهد بود. سازنده همچنین در مورد بسیاری از آرگومان های مورد استفاده در هر روش و مهمتر از آن در مورد ساختار داده داخلی کلاس به شما می گوید. با این دانش، هر روش بعدی به مراتب آسان تر می شود. و – ضمن اینکه در مورد چرخه زندگی یک شی است – روش تخریبگر و حتی سریال سازی (در صورت وجود) نیز باید بخشی از این بخش باشد. فقط به همین دلیل، کدی که از دانش خاص یکسانی استفاده می کند باید با هم ترکیب شود تا جستجوها را به حداقل برساند و کد را بیشتر مستندسازی کند.
تنها روش‌های دیگری که به بخش‌هایی از ساختار داده داخلی می‌رسند باید روش‌های گیرنده و تنظیم‌کننده باشند – که به عنوان دسترسی‌ها نیز شناخته می‌شوند. اینها محتوای بلوک دوم متدها هستند. آنها معمولاً بسیار کوچک هستند و یک طرح کلی خوب و سریع از رابط داخلی و خارجی (API) و جریان داده آن به شما ارائه می دهند.
بعد متدهایی هستند که حاوی بیشترین خطوط کد هستند – اجازه دهید متدهای workhorse را فراخوانی کنیم. فقط باید تعداد کمی وجود داشته باشد و به خوبی نظر داده شود.
بخش چهارم شامل توابع و متدهای کمکی است که به قدری مختص این کلاس هستند که نباید در فضای نام خود انتزاع شوند. برخی ممکن است به شدت اعتراض کنند و این عمل بد و نقض هدف اعلام شده را نشان دهند: توانایی درک کلاس در یک خواندن. آنها می خواهند قبل از فراخوانی یک روش، محتوای آن را بدانند تا درک کاملی از آنچه اتفاق می افتد داشته باشند. در حالی که من با این موضع همدردی می کنم، اما حاوی سوء تفاهم هایی است. اول از همه، اکثر سازنده‌ها قبلاً متدهایی را که به ترتیب ما در زیر ظاهر می‌شوند فراخوانی می‌کنند – بنابراین هیچ قانونی نیست که بتوانیم در حین نگه داشتن ترتیب پیشنهادی از آن پیروی کنیم. ثانیاً، یک مفهوم قانون اصلی بیان شده ما، قانون فرعی است: از API عمومی به داخل. این به تنهایی روش های کمکی را در آخر قرار می دهد. اما بهترین دفاع هدف یک روش را به یاد می آورد. این یک تکه انتزاع است. اگر نیاز به دیدن اجزای داخلی ندارید، یک انتزاع معیوب ایجاد کرده اید. یا نام تابع به شما نمی گوید چه اتفاقی می افتد یا روش بسیار بزرگ (پیچیده) یا حتی بدتر است: دارای عوارض جانبی است.
مطمئناً رعایت همه اینها در ابتدا مستلزم نظم و انضباط است (بخوانید: درد). اما در دراز مدت نتیجه می دهد. خواندن، نگهداری و گسترش کد شما آسان تر می شود (همه آنچه با استفاده از OO وعده داده شده است). حتی نوشتن کلاس های جدید آسان تر می شود، زیرا دیگر به جزئیات زیادی فکر نمی کنید. شما آزاد شدید که روی مشکلات کاهش ناپذیری که کلاستان حل می کند تمرکز کنید. بنابراین لذت ببرید و قوانین را مطابق با حساسیت ها و نیازهای خود تنظیم کنید – اما ثابت قدم باشید.
