روش تعریف و استفاده از متغییرهای کانفیگ در برنامه

[freeman99]

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

- یه اشکال اینه که مثلا توی یک تابع میخوای از یه متغییر کانفیگ که قبلا در بخشهای دیگر برنامه اینکلود شده استفاده کنی، باید قبلش متغییر رو با global در داخل تابع در دسترس قرار بدی (از آرایه ‎$GLOBALS هم میشه استفاده کرد).

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

- یه اشکال دیگه نیاز به اینکلود کردن فایل کانفیگ مورد نظر در هرجای برنامه است که میخوایم از این متغییرها استفاده کنیم و قبل از اون این فایل اینکلود نشده یا ممکنه اینکلود نشده باشه (مثلا بعلت اجرای شرطی دستورات اینکلود در کدهای قبلی) و مثلا بخاطر پیچیدگی برنامه در این باب شک داشته باشیم که بنابراین مجبوریم اینکلود کنیم تا مطمئن باشیم این متغییرها همیشه در اون قسمت در دسترس هستن. کلا من میخوام از شر هرچی اینکلوده تا حد امکان راحت بشم تا کدهای برنامه خلوت تر و خوندن و تغییر و گسترش برنامه راحتتر بشه (تا اینجا از شر اینکلود تعریف کلاسها و توابع راحت شدم).

- شاید یه اشکال دیگه این باشه که تعداد زیادی متغییر رو در فضای گلوبال برنامه وارد میکنیم که به این شکل خطر تداخل با متغییرهای دیگر ممکنه پیش بیاد (مثلا یک نفر که برنامه رو میخواد توسعه بده یک متغییر همنام تعریف میکنه).

خب در این باب دو کار میشه کرد.
یکی اینکه میگن متغییرهای کانفیگ رو بجای متغییرهای عادی، بصورت ثابت تعریف کنیم (با define). اینطوری دیگه نیازی به استفاده از global و اینها نداریم و این از بوجود آمدن باگهای پنهان در برنامه هم جلوگیری میکنه. از نظر خوانایی هم بهتره (ولی همچنان ممکنه کانفیگ ها با ثابت های دیگر در برنامه اشتباه گرفته بشن).

اما یه روش دیگه درست کردن یک کلاس کانفیگ است. من فکر میکنم یه کلاس استاتیک درست کنم که بعد مثلا میخوام مقدار متغییر کانفیگ some_config_var رو بگیرم به این شکل عمل میکنم:

config::some_config_var
بنظرم میشه از متد جادویی ‎__get برای این کار استفاده کرد.
البته یه شکل دیگه هم میتونه اینطوری باشه:

config::value('some_config_var')
البته فکر میکنم شکل قبلی بهتر باشه چون مختصرتره.

خب این کلاس کانفیگ همزمان چند مشکل رو حل میکنه. اولا دیگه نیاز به global کردن رو نداریم، دوما نیاز به اینکلود کردن هم نداریم. سوما خوانایی خوبی به کد میده.
ضمنا با این حال فکر نمیکنم دیگه نیازی به تعریف کردن کانفیگ ها بصورت ثابت هم باشه!

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

[MMSHFE]

میتونید از الگوی Registry استفاده کنید. یک کلاس داشته باشین که به شما اجازه میده داخلش فیلد و... تعریف کنید. حالا کافیه هرجا خواستین مقداری رو با بقیه بخشها به اشتراک بگذارین، فرضاً این شکلی کار کنید:

Registry::set('host', 'localhost');
ودر جاهای مختلف برنامه میتونید با دستور زیر بخونیدش:

Registry::get('host');
یکسری مقادیر و تنظیمات رو هم از قبل توی کلاس مربوطه بعنوان مقادیر پیشفرض قرار بدین. اینطوری دیگه همه مقادیری که ثبت کردین، یکجا هستن و حتی میتونید با serialize و... بصورت متن در بیارین و توی دیتابیس بگذارین و با unserialize دوباره از دیتابیس بخونید و آبجکت بسازین و کلی کارهای دیگه. مسئله بارگذاری خودکار هم با Autoload حل میشه.

[aliphp1]

میتونید از الگوی Registry استفاده کنید. یک کلاس داشته باشین که به شما اجازه میده داخلش فیلد و... تعریف کنید. حالا کافیه هرجا خواستین مقداری رو با بقیه بخشها به اشتراک بگذارین، فرضاً این شکلی کار کنید:

Registry::set('host', 'localhost');
ودر جاهای مختلف برنامه میتونید با دستور زیر بخونیدش:

Registry::get('host');
یکسری مقادیر و تنظیمات رو هم از قبل توی کلاس مربوطه بعنوان مقادیر پیشفرض قرار بدین. اینطوری دیگه همه مقادیری که ثبت کردین، یکجا هستن و حتی میتونید با serialize و... بصورت متن در بیارین و توی دیتابیس بگذارین و با unserialize دوباره از دیتابیس بخونید و آبجکت بسازین و کلی کارهای دیگه. مسئله بارگذاری خودکار هم با Autoload حل میشه.

سلام
استاد میشه بگید این روش چه مزیت هایی داره ؟
در حوزه استفاده از رم چگونه است ؟

[freeman99]

خب من یه کلاس کانفیگ درست کردم.
روشی دسترسی به متغییرهای کانفیگ به این شکله:

$config->some_conf_var
ولی موضوع جالب اینکه من نمیتونم دقیقا در همه جا از این کلاس استفاده کنم. یک محدودهء کوچکی هست که مجبورم از همون روش دسترسی مستقیم برای متغییرهای کانفیگ خاصی استفاده کنم. اون کجاست؟ خب من ابتدای برنامه بر اساس متغییرهای کانفیگ debug_mode و log_errors سیستم گزارش خطا رو فعال و تنظیم میکنم. اگر بخوام در اونجا برای دسترسی به این متغییرها از کلاس کانفیگی که ساختم استفاده کنم، طبیعتا معناش اینه که تعریف کلاس کانفیگ رو قبل از اینکه سیستم گزارش خطا رو تنظیم کرده باشم اینکلود کردم و قبل از اینکه سیستم گزارش خطا تنظیم شده باشه دارم از این کلاس استفاده میکنم. خب این باعث میشه اگر در خود این کلاس خطا یا باگ و مشکلی باشه، ممکنه سیستم گزارش خطا هنوز درست تنظیم نشده باشه و اون مشکلات رو نمایش نده و لاگ نکنه.
بنابراین من فکر میکنم باید متغییرهای کانفیگ مربوط به تنظیمات سیستم گزارش خطا رو قبل از اینکلود کردن و استفاده از کلاس کانفیگ، بصورت دستی اینکلود و استفاده کنم. البته فقط درمورد این چند خط کد در فایل common.php در کل برنامه به این شکل عمل میشه، که بنظرم مشکلی نیست، چون هرچند یک مقدار انسجام این سیستم کانفیگ برنامه و خوانایی و هماهنگی کد رو بهم میزنه اما بهرحال بنظرم درستی و دقت سیستم گزارش خطا و اینکه تمام کدهای برنامه رو پوشش بده مهمتر از این مسئله است.

[freeman99]

میگم یه کار دیگه هم میشه کرد :متفکر:

بیام سیستم گزارش خطا رو ابتدا بطور کامل فعال کنم، بعد که کلاس کانفیگ رو اینکلود کردم بیام و مقدار این متغییرهای کانفیگ رو باهاش بخونم و بر اساس مقداری که دارن سیستم گزارش خطا رو تنظیم کنم. به این شکل اگر مشکلی در کلاس کانفیگ وجود داشته باشه یا موقع استفاده رخ بده، این مسئله صرفنظر از مقداری که متغییرهای کانفیگ debug_mode و log_errors دارن گزارش میشه.

بنظر شما مناسبه؟ منطق درستی داره؟
شاید بگیم که خب اگر مثلا نمایش پیامهای خطا به کاربر رو در کانفیگ غیرفعال کرده باشیم، به این شکل اگر عمل کنیم و اگر مشکلی در کلاس کانفیگ رخ بده اونوقت این پیامها به کاربر نمایش داده میشن! ولی فکر نمیکنم این مسئله مشکلی باشه چون عدم نمایش پیامهای خطا به کاربران بیشتر بر اساس مسائل امنیتی است یا حداقل بخش بزرگی از اون به این خاطره، و پیامهای خطاهای احتمالی مربوط به این بخش محدود و اولیه از برنامه هم بنظر نمیرسه که خطر امنیتی ایجاد کنن. بهرحال هم که این مسئله نمیخواد زیاد رخ بده چون احتمالش خیلی کمه که در این بخش کوچک و ساده از برنامه مشکل پنهانی باشه یا بعدا بر اثر تغییرات بوجود بیان و از زیر مراحل توسعه و تست بدون اینکه آشکار بشه عبور کنه بنابراین چنین شرایطی به ندرت ممکنه اتفاق بیفته، و بنابراین از نظر تجربهء کاربری هم فکر نمیکنم مسئلهء جدی ای در کار باشه!

[freeman99]

$config->some_conf_var

ای بابا اینم توی توابع مشکل global نبودن رو داره.
باید کلاسش رو استاتیک کنم!
نشد از _get استفاده کنم چون برای پراپرتی های استاتیک کار نمیکنه. بنابراین مجبورم از یه شکلی مثل این استفاده کنم:

config::value('some_config_var')
میخواستم کد نویسیش هرچه کوتاهتر و راحتتر بشه، ولی مث اینکه چاره ای نیست!
آهان یه راه حل دیگه هم بنظرم رسیده بود. از یه تابع استفاده کنم چطوره؟ یعنی مثلا کدم اینطوری میشه:

config('some_config_var')
الان اینجا config یک تابع است.
البته اون روش قبلی بنظرم یک مقدار خواناتره.
اوه نه نه اشتباه کردم! چون الان برنامم طوریه که برای فراخوانی توابع باید اینطوری بنویسم:

func::config('some_config_var')
خب اینم که کوتاهتر نیست!

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

[MMSHFE]

اگه از namespaceها به خوبی استفاده کنین و فرضاً نام هر پوشه رو بعنوان فضای نام درنظر بگیرین اونوقت میتونین از کلاس Registry که گفتم، با فرض اینکه در مسیر webroot/inc قرار داره، اینطوری استفاده کنید:

use inc\Registry as R;
echo R::get('some_config_var');

[freeman99]

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

<?php
if(ini_get('register_globals')) exit("<center><h3>Error: Turn that damned register globals off!</h3></center>");
if(!defined('CAN_INCLUDE')) exit("<center><h3>Error: Direct access denied!</h3></center>");

class config {

private static $vars=array();

//================================================== =======================

public static function v($var_name) {

if(empty(self::$vars)) {
echo 'loading config vars...';
foreach(glob(ROOT.'include/config/config_*.php') as $filename) require $filename;
unset($filename, $tmp18, $username_php_re, $username_js_re);
foreach(get_defined_vars() as $name => $value) self::$vars[$name] = $value;
}

if(isset(self::$vars[$var_name])) return self::$vars[$var_name];
else trigger_error("reg8log: class config: error: '$var_name' not found!", E_USER_ERROR);

}

//================================================== =======================

}

?>
در اولین بار که اجرا میشه میاد و تمام فایلهای کانفیگ برنامه رو اینکلود میکنه و بعد متغییرهایی رو که تعریف کردن در آرایهء داخلی خودش ذخیره میکنه.
فقط بحثی که میمونه اینه که تعداد فایلهای کانفیگ 11 تاست (ممکنه بعدا بیشتر هم بشه) و اینکه در هر درخواست 11 تا فایل اضافی رو یک جا اینکلود کنیم از نظر پرفورمنس جالب بنظر نمیاد. هرچند میدونید که من روی پرفورمنس اصلا وسواسی نیستم و با بهینه سازیهای جزیی مخالفم، ولی فکر کنم بهینه سازی این بد نباشه چون بنظر بهینه سازی نسبتا درشتی میاد و از طرف دیگر پیاده سازیش هم سیستم جالبی میتونه بشه که در موارد دیگری هم شاید به درد بخوره. برای بهینه سازیش من فکر کردم که این 11 تا فایل رو برنامه یک بار میخونه و بعد متغییرهای کل اونا رو توی یک فایل کش مجتمع میکنه. اینطوری در دفعات بعد بجای 11 تا فایل فقط یک فایل اینکلود میشه. ولی برای آپدیت هم باید فکری بکنیم که اگر محتویات فایلهای کانفیگ تغییر کردن، یعنی مثلا مقدار یک متغییر کانفیگ رو تغییر دادیم، برنامه متوجه بشه و کش خودش رو آپدیت کنه. برای این فکر کنم باید با تابع filemtime تاریخ آخرین ویرایش فایلهای کانفیگ رو بخونم و از این طریق برنامه بفهمه که آیا تغییر کردن یا نه. البته باید در نظر داشت بهرحال اینم یک عملیات در سطح سیستم فایل بر روی همون تعداد 11 تا فایل است، ولی فکر کنم بهرحال از اینکلود کردن 11 تا فایل خیلی سریعتر باشه!
البته باید چک کنم اگر فایلی هم اضافه شده بود بازم کش باید آپدیت بشه. ولی خب خوبیش اینه که این کار فقط وقتی لازمه انجام بشه که یک متغییر کانفیگ درخواست بشه که در کش وجود نداشته باشه.

البته بازم باید امکان نوشتن و خواندن فایل کش چک بشه در برنامه. اگر نمیشد از فایل کش استفاده کرد اونوقت باید باز به اون روش ساده برگشت. البته میشه از سشن در این حالت برای ذخیرهء موقتی کش استفاده کرد. اینطوری عمر کش محدوده به عمر سشن، و ضمنا تعداد زیادی متغییر هم ریخته میشه توی سشن (باید دقت کرد که به ازای هر کاربر یک سشن مجزا داریم و دیگه مثل فایل فقط یکی نیست). ولی با این وجود من فکر میکنم بازم ایدهء درستی باشه و از اینکه در هر درخواست بخوایم 11 تا فایل رو اینکلود کنیم بهتره.

هووم ... :متفکر: چیزی رو از قلم ننداختم؟

[freeman99]

یه کلاس کانفیگ واسه برنامه خودم نوشتم که خودم خیلی خوشم اومد بنظرم چیز جالبی شده!
سورسش: https://github.com/ferchang/reg8log/blob/efd69254110039226df39108e1a4ba053d66bae3/include/class/class_config.php

چیز عمده ای که بهش اضافه کردم سیستم کشه.
در این قسمت:

$cache_method=array('file', 'sess');
مشخص میکنیم که کش خودش رو در کجا ذخیره کنه.
الان من اولی رو file گذاشتم و دومی رو sess، یعنی سیستم میتونه هم از فایل و هم از سشن برای ذخیره کش خودش استفاده کنه. ترتیبش هم مهمه و این امکان تنظیم و انتخاب دقیق تری رو به سیستم میده. مثلا اینجا چون فایل رو اول گذاشتم و سشن رو دوم، سیستم اول تلاش میکنه از فایل بعنوان کش استفاده کنه، اگر نتونست از فایل استفاده کنه، مثلا بخاطر نداشتن پرمیشن نوشتن در فایل، اونوقت به استفاده از سشن fallback میکنه. حالا اگر گزینهء دوم رو از آرایه حذف کنیم اصلا از سشن استفاده نمیکنه و بنابراین یا باید پرمیشن فایل مشکلی نداشته باشه و یا سیستم در هر درخواست کل فایلهای کانفیگ اصلی رو میخونه.
حالا اگر sess اول اومده بود و file دوم، این یعنی اینکه سیستم از سشن استفاده میکنه، ولی یک نسخه از کش رو در فایل هم داره که وقتی سشن در دسترس نبود (مثلا کاربر مرورگرش رو تازه باز کرده و سشن قبلی که کش متغییرهای کانفیگ ما توش بود از بین رفته) اونوقت میاد و از فایل کش متغییرهای کانفیگ رو میخونه و میریزه توی سشن و در دفعات بعد از سشن استفاده میشه.
اگر آرایه خالی باشه هم که کلا کش غیرفعال میشه و سیستم هربار مجبوره تمام فایلهای کانفیگ رو مستقیما بخونه.
خلاصه آخر امکان پیکربندی!

متد is_cache_valid هم که قبلا یک stub بود الان کدش رو نوشتم و برای بررسی اعتبار کش بررسی میکنه که آیا در دایرکتوری کانفیگ فایلی با زمان ویرایش جدیدتر از زمان ذخیرهء کش وجود داره یا نه. البته برای این هم امکانات کشینگ گذاشتم که قابل پیکربندیه. با متغییر cache_validation_interval که یک عدد برحسب ثانیه است مشخص میکنیم که اگر اعتبارسنجی کش انجام شد بعدش تا چه مدتی کش معتبر فرض بشه. اگر هم مقدارش روی صفر باشه یعنی کش رو معتبر فرض نکنه و هر بار چک کنه (این بخصوص برای موقع توسعه و تست به درد میخوره).

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

آخرش به کمک این کلاس ساختار فایلهای کانفیگ خودم رو حفظ کردم و هر 11 تاش رو نگه داشتم :قهقهه:

راستی میگم من چقدر عاشق این کلاسهای استاتیک، متدهای استاتیک، پراپرتی های استاتیک شدم :لبخند:
همش استاتیک در استاتیک! مهندس میگم جون تو استاتیک هم خیلی کاربرد داره توی این موارد واقعا به درد میخوره ها :متفکر:
بنظرت استایل کدنویسیم خیلی بهتر نشده؟

[MMSHFE]

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

[freeman99]

قدم به قدم. قبلا هم گفتم. فعلا نمیخوام ساختار کلی برنامه رو عوض کنم. فقط دارم یکسری بهبودها و برطرف کردن موارد کلی و درشت رو انجام میدم.
قبلا مثلا نمیخواستم و نمیتونستم اینقدر بیام روی طراحی یک کلاس و یکسری مسائل کلیشه ای که همه میدونن وقت بذارم و مثلا یادت هست شما گفتی این چه برنامه ایه یه قطعه کد رو همه جا کپی کردی و یه تابع براش تعریف نکردی، خودم میدونستم و اینقدر خنگ نبودم که، ولی اینقدر سرم با جزییات دیگر خود سیستم و منطق و الگوریتم های پیچیده شلوغ بود و مباحث امنیت و رمزنگاری هم اضافه بر اینها، که یعنی بگی حتی 30 ثانیه هم نمیخواستم ذهنم رو روی مسئلهء دیگری معطوف کنم ترجیح میدادم همون کد رو سریعا کپی پیست کنم و برگردم سر بقیهء کار، چون جزییات زیادی توی ذهنم بود و با کلی تحقیق و تحلیل به یک نتایج و مرحله ای از پیشرفت رسیده بودم که کافی بود مدتی وقفه بیفته و تمرکزم از بین بره تا از یکسری از این جزییات غفلت کنم یا دوباره مجبور بشم کار تحقیق و تحلیل درمورد یک مسئله ای رو از مراحل عقب تری شروع کنم.
شما حجم کد و جزییات و تعداد جدولها و فیلدهای پروژه منو مقایسه کن با بقیهء سیستمهای ثبت نام و لاگین که همه توی برنامه هاشون درست میکنن، بنظرم تایید میکنید که تفاوت فاحشی وجود داره، و این همه کد و داستان و پیچیدگی بی دلیل یا از روی ناشی بودن نبوده. من خواستم یه ویژگیها و دقت و امنیت در سطح بالا رو که مد نظرم بود توی این پروژه پیاده سازی کنم، وگرنه اگر میخواستم صرفا یه چیزی مثل همونا که بقیه هم درست میکن درست کنم که کاری نداشت اصلا احتمالا این پروژه رو شروع هم نمیکردم. اینکه دوتا فیلد ثبت نام رو بگیری بریزی توی جدول یه پسورد رو با md5 هش کنی و بعد موقع لاگین نام کاربری و پسورد رو مطابقت بدی و یکسری مخلفات عادی دیگه که کاری نداره چیزی نیست حجم و پیچیدگی زیادی نداره که بخوام پیشاپیش نگرانش باشم! ولی من گستردگی و جزییات و پیچیدگی های خیلی بیشتری رو میتونستم تصور کنم و میخواستم اون سیستم کامل و دقیق و با امنیت در سطح حرفه ای که مد نظرم هست رو طراحی و پیاده سازی کنم. چون میدونستم خیلی کار میبره (نه فقط کدنویسی، بلکه کلی تحقیق و تحلیل ذهنی هم میخواد و همینطوری نیست فقط کد بزنی تست کنی کار میکنه بزنی و بری!) و بعدا تحت فشار و عجله و محدودیت وقت ممکنه نتونم و مجبور بشم از خیرش بگذرم و مثل بقیه فقط یه چیزی سرهم کنم که در ظاهر کار میکنه و بدون مشکله، ولی خیلی اصول و جزییات دقیق رو رعایت نکرده.
الان چون بخش عمده اون مراحل انجام و قبلا حل شده، میتونم بیشتر روی مسائل بعدی از دید خودم تمرکز کنم.
من دارم از روش تکاملی که بنظرم خودم روش عاقلانه و بهتره استفاده میکنم. الان هنوز یکسری بهبودها و کمبودها در اصل خود برنامه هست که دارم اعمال میکنم ولی کد رو هم در کنارش میخوام تمیزتر و مختصرتر بکنم که راحتتر و سریعتر بشه روی منطق ها و بهبود و تغییر و گسترش برنامه و خواندن و فهم کدهاش کار کرد و البته از نظر استفاده کاربردی و ترکیب با برنامه ها و سیستمها و کدهای دیگر هم پیشرفت داشته باشه (مثلا من الان تمام متغییرهای سشن این پروژه رو بردم توی یک آرایهء مخصوص خودش که احتمالا با متغییرهای سشن برنامه ها و سیستمهای دیگر تداخل نکنه - ولی قبلا اینطور نبود چون توی مرحله ای نبودم که به راحتی ترکیب این برنامه با برنامه ها و سیستمهای دیگر بخوام فکر کنم و اهمیت زیادی به این مسئله بدم). کار مرحلهء قبل بخش عمدش تحقیق و محک زدن ایده ها و جزییات منطق و امنیت بود و مسلط شدن به جزییات کدنویسی پیاده سازی اون ایده ها و روشها و انجام دادن این بخش حجمی کار تا اینکه بخواد یه برنامهء کاربردی آمادهء استفاده روزمره باشه. یه جورایی Prototype اولیه بود. هنوزم بعضی بخشهاش رو باید تغییر بدم (مثلا الگوریتم هشش رو باید عوض کنم bcrypt بذارم)، ولی بخش عمدهء تحقیق و تست و تصمیمگیری قبلا انجام شده و الان بینش و احاطهء خیلی بهتری نسبت به کلیت داستان و تمام جوانب این چنین پروژه ای دارم.

[MMSHFE]

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

من هم گفتم کم کم