My Experience 3

[MiLo]

تو این بخش راجب decleration file حرف بزنیم

مخفی کننده

 

 

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

 

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

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

مثال زیرو ببین

 

//app.js
export function add(a, b) {
	return a + b;
}
export function subtract(a, b) {
	return a - b;
}

الان ما دوتا فانکشن داریم؛ ولی ما نه تایپ ورودیو میدونیم نه خروجیشو! اینجاست که میاییم براش decleration file تعریف میکنیم و این مشکلو برطرف میکنیم

//app.d.ts
export function add(a: number, b: number): number;
export function subtract(a: number, b: number): number;

توی decleration file اومدیم گفتیم ما در فایل app.js دوتا فانکشن داریم به اسم add و subtract، حالا این دو فانکشن ورودی هاشون از نوع نامبر و خروجی هاشونم از نامبره! اینشکلی وقتی میخوایم از app.js توی فایلای تایپ اسکریپتی استفاده کنیم همچنان type ckecking رو داریم با اینکه فایل جاوا اسکریپتیه.

 

 

 

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

 

-خب اول از همه باید بدونیم encapsulation یک مفهوم و یک طرز فکر برای حل یک مسئلس. نه صرفا ی چارچوب برای کدنوشتن. حالا بریم ببینیم چه مشکلی رو ازمون حل میکنه.

 

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

 

-خب حالا ما مشکلو پیدا کردیم. ما مشکلمون اینه که گاهی اوقات جزئیاتیو در اختیار کاربر میزاریم که ممکنه باعث خرابیه سیستم بشن. حالا چجوری بفهمیم چه چیزی این ویژگی رو داره و چجوری ازش جلوگیری کنیم؟ اینجاست که encapsulation به کمکمون میاد.

 

-مفهوم encapsulation به زبون ساده میگه شما حد ممکن باید جزئیات رو از دید کلاینت مخفی کنی. حالا این مخفی کردنه صرفا این نیست که شما لاجیک رو داخلش پرایوت نگه داری. مثل اون بانکس که اجازه دسترسی به داخل یک سیستم رو ندی. و این اصل به ما کمک میکنه که شما اپلیکیشن ایمن تر و قابل اعتماد تری داشته باشی.

 

-مثال خیلی سادش ماشینه!  مشکل ماشین های ما اینه که اگر ما فرض کنید کرم داشته باشیم و بخوایم تست کنیم و از دنده 5 یهو بکشیم دنده 1 ماشین رو باید ساعت 9 بزاریم دم در(ماشینای دنده ای)، خب اینجا ما باید جزئی به اسم دنده رو encapsulate کنیم که از این اتفاق جلوگیری کنیم!

 

-حالا چرا گفتم که فکر میکنین ازش خبر دارین؟ چون اکثر برنامه نویسا وقتی اسم encapsulation میاد ذهنشون میره سمت چیزی به اسم access modifier ها، که توی زبانی مثل typescript به (public, private, protected) میشناسیمشون، و هدف این قسمت این بود که شما متوجه بشی صرفا پرایوت کردن یه متد یا یک پراپرتی اسمش encapsulation نیست، و این یک طرز فکر برای حل یک مسئله بزرگتره! اینکه توی شئ گرایی ما با access modifier ها encapsulate میکنیم یک سری چیزهارو، دلیل نمیشه بدون اون ها ما نتونیم encapsulation داشته باشیم.

ویرایش شده January 22 توسط MiLo

[Alimojaveri]

عالی

ویرایش شده January 22 توسط alimojavery1

[Integer]

در ۱۴۰۴/۱۱/۲ در 14:45، MiLo گفته است:

تو این بخش راجب decleration file حرف بزنیم

  نمایش محتوا مخفی

 

 

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

 

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

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

مثال زیرو ببین

 

//app.js
export function add(a, b) {
	return a + b;
}
export function subtract(a, b) {
	return a - b;
}

الان ما دوتا فانکشن داریم؛ ولی ما نه تایپ ورودیو میدونیم نه خروجیشو! اینجاست که میاییم براش decleration file تعریف میکنیم و این مشکلو برطرف میکنیم

//app.d.ts
export function add(a: number, b: number): number;
export function subtract(a: number, b: number): number;

توی decleration file اومدیم گفتیم ما در فایل app.js دوتا فانکشن داریم به اسم add و subtract، حالا این دو فانکشن ورودی هاشون از نوع نامبر و خروجی هاشونم از نامبره! اینشکلی وقتی میخوایم از app.js توی فایلای تایپ اسکریپتی استفاده کنیم همچنان type ckecking رو داریم با اینکه فایل جاوا اسکریپتیه.

 

 

 

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

 

-خب اول از همه باید بدونیم encapsulation یک مفهوم و یک طرز فکر برای حل یک مسئلس. نه صرفا ی چارچوب برای کدنوشتن. حالا بریم ببینیم چه مشکلی رو ازمون حل میکنه.

 

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

 

-خب حالا ما مشکلو پیدا کردیم. ما مشکلمون اینه که گاهی اوقات جزئیاتیو در اختیار کاربر میزاریم که ممکنه باعث خرابیه سیستم بشن. حالا چجوری بفهمیم چه چیزی این ویژگی رو داره و چجوری ازش جلوگیری کنیم؟ اینجاست که encapsulation به کمکمون میاد.

 

-مفهوم encapsulation به زبون ساده میگه شما حد ممکن باید جزئیات رو از دید کلاینت مخفی کنی. حالا این مخفی کردنه صرفا این نیست که شما لاجیک رو داخلش پرایوت نگه داری. مثل اون بانکس که اجازه دسترسی به داخل یک سیستم رو ندی. و این اصل به ما کمک میکنه که شما اپلیکیشن ایمن تر و قابل اعتماد تری داشته باشی.

 

-مثال خیلی سادش ماشینه!  مشکل ماشین های ما اینه که اگر ما فرض کنید کرم داشته باشیم و بخوایم تست کنیم و از دنده 5 یهو بکشیم دنده 1 ماشین رو باید ساعت 9 بزاریم دم در(ماشینای دنده ای)، خب اینجا ما باید جزئی به اسم دنده رو encapsulate کنیم که از این اتفاق جلوگیری کنیم!

 

-حالا چرا گفتم که فکر میکنین ازش خبر دارین؟ چون اکثر برنامه نویسا وقتی اسم encapsulation میاد ذهنشون میره سمت چیزی به اسم access modifier ها، که توی زبانی مثل typescript به (public, private, protected) میشناسیمشون، و هدف این قسمت این بود که شما متوجه بشی صرفا پرایوت کردن یه متد یا یک پراپرتی اسمش encapsulation نیست، و این یک طرز فکر برای حل یک مسئله بزرگتره! اینکه توی شئ گرایی ما با access modifier ها encapsulate میکنیم یک سری چیزهارو، دلیل نمیشه بدون اون ها ما نتونیم encapsulation داشته باشیم.

درود خیلی ممنونم ازتون بابت مطلبتون

فقط یه موضوعی هستش

سعی کنید زیاد روی شی گرایی تمرکز نکنید

مدل های بی شمار تری هستن که میتونید انجام بدید:

Functional Programming (مثل پایتون): توابع سطح بالا, لامبدا, و... آینده دست این پارادایم هستش, سعی کنید خوب متوجهش بشید

Actor & Supervisor: به جای Async I/O سنتی و Parallel عه سنگین, سعی کنید Actor رو یاد بگیرید

Actor ها یک سری پراسس های خیلی کوچک با میل باکس هاشون هستن که شما میگید مثلا این پیام که اومد توی میل باکست این کارو کن

شما میتونید بینهایت ها اکتور داشته باشید, هیچ اکتوری روی دیگری تاثیر نداره (مگر اینکه One_For_All (یعنی یکی کرش شد کل سیستم بخوابه) باشه, اگر One_For_One (هرکی واسه خودش) یا چیز دیگه ای باشه, فقط اکتور مربوطه میخوابه), و سرپرست ها (Supervisors) هم حتما سعی کنید خیلی خوب متوجه بشید

فرض کنید یه اکتور, یه بازیگر دارید, سر صحنه یهو میمیره (کرش میکنه), الان اینجا یه هیلر داریم که اینو میاد و زنده میکنه (بر میگردونه پراسس رو) که بهش میگیم سوپروایزر, همون One_For_All و One_For_One و... اینا همون واسه سرپرست ها هستن (مثال واقعی استفاده: بازی های آنلاین (هرکی دیسکانکت شد کل سیستم نخوابه), تلکام ها (اگر یکی از بین رفت کل سیستم از بین نره), فضا های ریال تایم (اگر ارتباط کاربر قطع شد برش گردون), سیستم های مخابراتی و...) (که زبان Erlang/Elixir دارن نتیو هم Actor رو (به کمک BEAM) و هم Supervisor رو (به کمک OTP))

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