آموزش جاوا قسمت اول

[*بانو بهار*]

توی چند جلسه آینده، شروع به پیاده سازی یک مثال عملی میکنیم و تمامی موارد گفته شده را تا حدودی در اون استفاده می‌کنیم.

� پیاده سازی اولیه به صورت CommandLine هست و در صورت نیاز بعد از آن شروع به پایده سازی اون به صورت گرافیکی میکنیم.

پروژه اول هدف طراحی یه سیستم ATM هست، که چندین کاربر در آن وجود دارند که هر کاربر فقط یک حساب مشخص دارد و قابلیت‌های برداشت وجه،‌واریز وجه، انتقال وجه، اعلام موجودی و ۵ عملیات آخر پیاده سازی می‌شود.

در مرحله بعد یاد میگیریم چطور این اصلاعات رو در فایل ذخیره سازی کنیم و چطور بازیابی کنیم.

خوب بریم سراغ پیاده سازی این پروژه کوچک:

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

اولین قدم در طراحی یه سیستم در واقع شناسایی موجودیت‌های سیستم هست. در صورتی که خوب موجودیت هایی یک سیستم را تشخیص ندهیم تا انتهای پروژه مشکل خواهیم داشت و یا به بن‌بست برمی‌خوریم و نیاز به تغییرات کلی در ساختار پروژه هست.

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

نکته بعدی اینکه موجودیت‌های یک سیستم با توجه به تعریف مسئله و یا نیازها میتونند تغییر کنند. یعنی به خودی خود یه موجودیت باشند ولی با فرضیات و نیازهای مسئله موجودیت نباشند

خوب ببینیم چه موجودیت‌هایی میتونیم در ابتدا فرض کنیم:

۱- کاربر

۲- حساب

۳- شماره حساب

۴- بانک

۵- موجودی

۶-مدیر

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

حساب:

خوب با توجه به اینکه هر کاربر یک حساب دارد و اینکه حساب خودش دارای موجودی و تاریخ ثبت و همچنین شماره حساب هست پس منطقی میاد که به صورت یه موجودی باشد.

دقت کنید چون مسئله گفته هر کاربر یک حساب دارد پس میتونیم ویژگی‌های حساب رو به کاربر منتقل کنیم و موجودی جدیدی ایجاد نکنیم چون به ازای هر کاربر دقیقا یک حساب وجود دارد پس نیاز به تعریف جدیدی از حسابب نیست.

شماره حساب:

واقعا شماره حساب میتونه یه موجودیت باشد؟ آیا خود شماره حساب دارای ویژگی یا توانایی هست که اون رو به عنوان یه موجودیت مستقل در نظر گرفت؟ جواب این سوال خیر هست پس نباید به عنوان موجودیت در نظر گرفت.

بانک:

در کل سیستم ما فقط یک بانک وجود دارد. آیا نیاز هست باید رو به عنوان یه موجودیت در نظر گرفت؟

جواب این سوال این هست که موجودیت به تعداد نمونه ها نیست، باید ببنیم آیا میتوان برای آن ویژگی یا توانایی تعریف کنیم یا نه.

�پس بانک هم یک موجودیت مستقل به حساب میاد که مثلا مجموعه‌ای از کاربران در آن وجود دارند…

موجودی:

آیا خود موجودی داریا ویژگی یا توانایی هست؟ خیر

موجودی خودش یک ویژگی برای حساب یا کاربر هست پس نمیتونه خودش موجودیت مستقل باشه.

مدیر:

مدیر خودش یک نوع کاربر هست، با این تفاوت که فقط سطح دسترسی متفاوتی داره بنابراین نیاز نیست با کاربر متمایزش کرد و فقط تمایزی که داره میتونه یک ویژگی به نام سطح کاربری باشه که یک مشتری را از یک مدیر مجزا میکنه.

بیشتر فک کنید شاید موجودیت‌های دیگه سیستم داشته باشه که لازم هست اضافه شوند…

تا اینجا پس ما موجودیت‌های زیر رو داریم:

۱- بانک

۲-کاربر

۳- حساب

هنوز زمان کدنویسی نشده!!! الان باید برای هرکدوم از این موجودیت‌ها، ویژگی‌ها و توانای‌هاشون رو مشخص کنیم. یادآوری میکنم ویژگی‌ها همون fieldها هستن و توانایی همان method های یک کلاس هست.

�تشخیص اینکه چه ویژگی یا توانایی مربوط به کدام موجودیت هست بسیار مهم هست و باعث کاهش پیچیدگی سیستم می‌شود(به شدت)!

خوب برای راحتی کار مهندس‌نرم افزار ابزاری به نام UML معرفی کرده که در واقع ابزاری برای مدل کردن هست. ما هم برای نمایش موجودیت ها از این ابزار استفاده می‌کنیم.

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

هر بخشی از یک موجودیت در داخل UML از سه قسمت زیر تشکیلی شده است

۱- نام موجودیت که اگر دقت شود با حرف C نمایش داده میشود که بیانگر class هست

۲- ویژگی‌ها که با حرف f یا همان field نمایش داده می‌شود.� دقت کنید نام ویژگی در سمت چپ و نوع و type ان در سمت راست آن قرار می‌گیرد.

۳- توانایی ها یا متدها که با حرف m نمایش داده می‌شوندو در سمت چپ نام متد همراه با نوع ورودی ها نوشته می‌شود و در سمت راست خروجی متد.

دقت شود این سه بخش با یک خط از هم جدا می‌شوند.

خوب برای جلسه بعدی در مورد UML سیستم ATM که قرار پیاده سازی کنیم فک کنید و اون رو روی کاغذ بنویسید. در آینده ابزار این کار که با کامپویتر کشیده بشه



Read

 

[*بانو بهار*]

خوب جلسه پیش در مورد موجودیت های سیستم صحبت کردیم و قرار شد UML اون ها رو طراحی کنیم. برخلاف چیزی که شاید به ذهن خیلی ها برسه UML ها تا آخر پروژه همیشه در حال تغییر کردن و تکمیل شدن هستن پس نیاز نیست خیلی خیلی حساسیت نشون بدیم برای طراحی اون‌ها.

طراحی UML سیستم ما میتونه به صورت زیر باشه. همونجور هم که خودتون میدونید میتونید طراحی‌های مختلفی داشته باشه و قرار نیست طراحی همه سیستم‌ها شبیه هم باشند…

خوب موجودیت‌های ما:

۱- بانک

۲- کاربر

۳- حساب

۴- تراکنش

که ویژگی‌ها و توانایی اون‌ها و همچنین ارتباط این موجودیت ها با هم در این UML کاملا واضح هست.

نکته: خط قرمزی که در UML وجود دارد بیانگر کلاس داخلی (inner class) هستند که بعدا در موردشون صحبت میکنیم.

نکته: باکس Type رو اگر نگاه کنید، برخلاف سایر باکس‌ها به جای استفاده از علامت C که نمایانگر کلاس هستند از حرف E استفاده شده هست که بیانگر Enum بودن هست.

خوب یکی یکی بریم سراغ موجودیت‌های سیستم:

کلاس Bank

�

همون‌طور که میبینید این کلاس در واقع اطلاعات همه کاربران را در خود ذخیره می‌کند. برای اینکار مجموعه یا Set از کاربران در خود دارد. (یادآوری: تفاوت set با List در این بود که در مجموعه‌ها عضو تکراری وجود ندارد و همچنین ترتیب بین عناصر اهمیتی ندارد برخلاف List)

متغییری به نام currentUser وجود دارد که از جنس User هست و قرار هست کاربری که وارد سیستم بانک می‌شود و username و password خود را به درستی وارد کند و در واقع وارد سیستم شود در این متغییر نگهداری شود. در واقع این متغییر به کاربری که وارد سیستم شده است اشاره می‌کند.

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

و در انتها تابع menu که وظیفه نمایش منوی کاربری و اطلاعات کاربر هست و همچنین به کاربر اجازه انتخاب موارد و خدمات را می‌دهد.

نکته: در طراحی شاید لازم باشد توابع و یا فیلدهای بیشتری به کلاس‌ها اضافه شوند.

کلاس User

این کلاس وظیفه نگهداری اطلاعات کاربران هست. برای همین فیلدهای شماره کاربری، نام، فامیل، username و password را در خود دارد. هم چنین نمونه‌ای از کلاس Account که در واقع اطلاعات حساب کاربری در آن ذخیره شده‌اند.

همچنین List از تراکنش‌های که کاربر انجام داده است را باید ذخیره کند. دقت شود چون ترتیب تراکنش‌ها برای ما اهمیت دارد از ساختمان‌داده List استفاده شده‌اند.

متد withdrawal� برای پیاده سازی عملیات برداشت وجه از حساب کاربری کاربر هست. متد deposits� برای واریز وجه به حساب کاربری هست و در انتها متد transfer برای انتفال وجه بین کاربر و کاربر هدف (targetUser) نوشته شده است.

متد getLastTransactions نیر برای دریافت آخرین تراکنش‌های کاربر طراحی شده است.

کلاس Account

این کلاس اطلاعات حساب کابری را در خود ذخیره می‌کند. همچنین موجودی کاربر(فیلد Value)

دو متد incValue و decValue برای افزایش و کاهش موجودی حساب کاربری طراحی شده است.

کلاس Transaction

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

همان‌طور که میبینم Type به صورت Enum تعریف شده است ویک کلاس نیست بلکه Enum هست! همچنین اگر دقت شود همیشه میگفتیم در داخل یک فایل فقط یک کلاس یا Enum وجود داشته باشد ولی ما اینجا این قانون را نقض کردیم! که در ادامه توضیح میدیم چرا اینکار رو کردیم.

ولی Enum چی هست؟

در جاوا ساختاری تحت عنوان Enumeration وجود دارد که به اختصار enum گفته می‌شود و مفهوم "شمارش" را در برنامه نویسی در اختیار ما می‌گذارد.

به طور کلی اگه مفهومی دارای چندحالت مختلف ولی ثابت باشند و قرار نباشد در حین برنام هبه صورت داینامیک تغییر کند از مفهوم شمارش باید استفاده شود، شبیه:



Read

 

[*بانو بهار*]

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

در واقع ما وقتی متغییرهای چند وضعیتی داشته باشیم که در طول برنامه تغییر نمی‌کنند باید از مفهوم Enum استفاده کنیم.

کلاس داخلی یا inner class

در واقع ما نباید در داخل یک فایل بیشتر از یه کلاس یا Enum و … داشته باشیم ولی در بعضی مواقع استثناهایی وجود دارد. وقتی یک کلاس یا یک Enum به تنهایی مفهومی نداشته باشد ولی به اندازه کافی مستقل باشد ما به ناچار باید یک کلاس یاEnum تعریف کنیم ولی چون به وجود یه کلاس دیگری نیازمند هست ما آن را داخل آن کلاس میگذاریم.

مثلا همین مثال رو دقت کنید، مفهوم TYPE به تنهایی مفهومی ندارد اگر کلاس Transaction وجود نداشته باشد. یعنی تا زمانی Type مفهوم داشته باشد که در ارتباط با کلاس Transaction باشد. بنابراین ما enum برای Type را به صورت innerمی‌نویسم چون وابستگی به کلاس Transaction دارد.

خوب از دوستان تقاضا دارم برای جلسه بعدی این کلاس‌ها را پیاده سازی کنند و در صورتی که بتونند متدها را نیز پیاده سازی کنند خیلی خیلی عالی می‌شود