```
WEBVTT

00:00.170 --> 00:08.750
خیلی خوب، پس بیایید یک قدم جلوتر برویم و از وراثت سازنده با کلاس‌های مشتق چندگانه استفاده کنیم.

00:08.750 --> 00:10.820
در ویدیوی قبلی خود، این مثال از کارمند که یک شخص است را داشتیم.

00:10.820 --> 00:16.430
اکنون، یک کارمند می‌تواند موقعیت‌های مختلفی داشته باشد و هر یک از این موقعیت‌ها می‌تواند به یک دسته‌ای مانند مدیر یا توسعه‌دهنده یا منابع انسانی و غیره تقسیم شود.

00:16.430 --> 00:24.740
خیلی خوب.

00:24.740 --> 00:32.690
بنابراین من یک کلاس جدید به نام مدیر ایجاد می‌کنم که همچنین یک کارمند خواهد بود.

00:32.690 --> 00:33.260
پس این یک لایه دیگر از وراثت است.

00:33.260 --> 00:41.180
پس به نوعی چند سطحی است.

00:41.180 --> 00:48.920
و به وضوح نیاز به افزودن سازنده داریم.

00:48.920 --> 00:53.600
بنابراین می‌خواهم سازنده را ایجاد کنم و می‌توانید ببینید که سازنده برای من به همراه تمام اطلاعات پایه‌ای که نیاز داریم ایجاد شده است.

00:53.600 --> 01:00.470
پس ما باید نام، سن، عنوان شغلی و کارمند را به آن بدهیم.

01:00.470 --> 01:03.770
و حالا می‌توانیم ویژگی‌های بیشتری به مدیر اضافه کنیم.

01:03.770 --> 01:07.460
برای مثال، چند نفر را که آن مدیر مدیریت می‌کند.

01:07.460 --> 01:10.760
بنابراین این می‌تواند اندازه تیم باشد، برای مثال.

01:10.760 --> 01:15.170
که می‌تواند ویژگی خاصی برای مدیر باشد.

01:15.170 --> 01:23.900
حالا می‌توانید جزئیات بیشتری به مدیر در این مرحله اضافه کنید که ما همچنین اندازه تیم را می‌گذرانیم.

01:23.900 --> 01:35.600
پس می‌بینید که ID (شمارنده) به طور خودکار این کار را انجام داده است.

01:35.600 --> 01:42.650
بنابراین اینجا می‌بینید که شناسنامه کارمند و بعد از آن اندازه تیم را به آن می‌دهیم.

01:42.650 --> 01:44.450
و در سازنده.

01:44.450 --> 01:50.930
بنابراین در داخل آکولادها، ما هر اندازه تیمی را که به مدیر داده‌ایم به ویژگی اندازه تیم مربوطه اختصاص می‌دهیم، تا به درستی نمایش داده و ذخیره شود.

01:50.930 --> 01:56.480
و حالا علاوه بر این، من از یک متد دیگر که اطلاعات مدیر را نمایش می‌دهد استفاده می‌کنم.

01:56.480 --> 02:11.210
و آنچه نمایش اطلاعات مدیر انجام می‌دهد، نمایش اطلاعات کارمند است.

02:11.210 --> 02:14.960
به علاوه اینکه در مورد اندازه تیم به ما اطلاعات می‌دهد.

02:14.960 --> 02:17.480
و به عنوان مثال اطلاعات کارمند.

02:17.480 --> 02:19.520
بله، اینجا خوب است.

02:19.520 --> 02:24.200
پس می‌گویم اندازه تیم را به دو نقطه‌گذاری می‌زنم.

02:24.200 --> 02:30.530
و سپس در داخل آکولادها، ویژگی اندازه تیم را اضافه می‌کنم، خوب.

02:30.530 --> 02:37.670
پس حالا زمانی که ما یک شی از مدیر خود را ایجاد می‌کنیم، خواهیم دید که تمام این موارد چگونه به هم می‌پیوندد.

02:37.670 --> 02:39.410
ما جو داریم.

02:39.410 --> 02:43.940
و حالا یک مدیر به نام کارل اضافه می‌کنیم.

02:43.940 --> 02:47.360
و کارل قرار است یک مدیر جدید باشد.

02:47.360 --> 02:55.100
و حالا باید تمام این اطلاعات را همراه کنیم تا بتوانیم نام و غیره را بگذرانیم.

02:55.100 --> 02:58.430
بیایید ببینیم چه اتفاقی می‌افتد وقتی جو و اندازه تیم را بگذاریم.

02:58.640 --> 03:00.140
متأسفانه، این کار نمی‌کند.

03:00.140 --> 03:06.980
امیدوار بودم که چیزی با C-sharp 12 تغییر کرده باشد، جایی که فقط تمام ویژگی‌های جو را که مرتبط با مدیر است، بپذیرد.

03:06.980 --> 03:10.520
پس ما باید نام را بگذرانیم.

03:10.520 --> 03:12.050
پس من به او می‌گویم کارل.

03:12.050 --> 03:13.580
من یک نام به او می‌دهم، سنی معادل 45.

03:13.580 --> 03:17.450
او قرار است یک مدیر باشد و شناسنامه کارمندی او چیزی دیگر خواهد بود.

03:17.540 --> 03:24.200
و اندازه تیم او قرار است، بگذارید بگوییم، هفت باشد که می‌گویند اندازه تیم ایده آلی است که یک مدیر می‌تواند مدیریت کند.

03:24.200 --> 03:29.990
پس همین طور داریم.

03:29.990 --> 03:31.100
ما مدیر کارل را داریم.

03:31.100 --> 03:32.720
و بیایید از کارل استفاده کنیم تا نه فقط اطلاعات کارمند، بلکه اطلاعات مدیر را نمایش دهیم.

03:32.720 --> 03:34.790
پس همه جزئیات آنجا هستند.

03:34.790 --> 03:42.170
پس بیایید بیانیه جو را از اینجا حذف کنیم.

03:42.170 --> 03:45.770
چون ما فقط می‌خواهیم کارل داشته باشیم و ببینیم چه اتفاقی با این سازنده چند سطحی می‌افتد.

03:45.770 --> 03:52.910
پس می‌بینید که سازنده شخص فراخوانی می‌شود.

03:52.910 --> 03:54.680
سپس سازنده کارمند فراخوانی می‌شود.

03:54.680 --> 03:57.440
سپس جزئیات مربوط به نام را نشان می‌دهیم.

03:57.440 --> 03:59.780
خوب، در مورد شخص.

03:59.780 --> 04:03.680
سپس جزئیات مربوط به کارمند را نشان می‌دهیم و سپس اندازه تیم را نشان می‌دهیم.

04:03.680 --> 04:04.700
بنابراین جزئیات مربوط به مدیر.

04:04.700 --> 04:09.530
پس می‌بینید که این‌ها سه لایه هستند که الان ما فراخوانی می‌کنیم.

04:09.530 --> 04:12.230
و ما به‌طور مؤثری بیشتر از آنچه را که در مورد وراثت آموخته‌ایم، به کار می‌بریم.

04:12.230 --> 04:18.170
پس ما متد والد را در داخل متد فرزند فراخوانی می‌کنیم.

04:18.170 --> 04:24.170
و ما همین کار را اینجا انجام می‌دهیم.

04:24.170 --> 04:27.530
پس ما متد والد را فراخوانی می‌کنیم، نه متد اجدادی، بلکه متد والد که به طور داخلی

04:27.530 --> 04:34.850
متد اجدادی را برای نمایش اطلاعات مدیر فراخوانی می‌کند.

04:34.850 --> 04:40.160
حالا، شما به‌طور منطقی می‌توانید آن را به هر طریقی که می‌خواهید گسترش دهید، مانند ویژگی‌های قابل توجه تر.

04:40.160 --> 04:45.890
اما نکته جالب اینجاست که ما می‌بینیم آنچه که ما انجام دادیم هم در چندین سطح و هم با کلاس‌های مشتق چندگانه کار می‌کند.

04:45.890 --> 04:55.370
پس این فقط نشان می‌دهد که شما می‌توانید این کار را به اندازه‌ای که می‌خواهید پیچیده کنید.

04:55.370 --> 04:59.570
و چرا مهم است که یک روش کاملاً واضح و تمیز برای ساخت کلاس پایه وجود داشته باشد، زیرا هرکسی که

04:59.570 --> 05:08.560
کلاس پایه را بنا می‌کند، پایه‌ای برای کدهای دیگر ما می‌سازد.

05:08.560 --> 05:14.320
پس حالا ممکن است درک کنید چرا مهم است که وقتی یک کلاس پایه ایجاد شد، شما نمی‌بایست تنها آن را ویرایش کنید.

05:14.350 --> 05:22.900
اگر چندین کلاس مشتق وجود داشته باشد، زیرا در این صورت شما احتمالاً باید کلاس‌های مشتق را نیز ویرایش کنید.

05:22.900 --> 05:34.990
زیرا اگر حالا بگویم خوب، ما تنها سن و نام را برای یک شخص نداریم، بلکه همچنین رنگ مو هم داریم.

05:34.990 --> 05:36.310
پس بیایید بگوییم که public string یا آدرس، از آنجایی که ID به من می‌دهد آدرس را.

05:36.310 --> 05:41.350
پس بیا از آن استفاده کنیم.

05:41.350 --> 05:45.700
پس حالا می‌خواهم آدرس را نیز داشته باشم.

05:45.700 --> 05:52.390
پس شما می‌بینید که آدرس به پارامترها در سازنده اضافه شده و همچنین در اینجا به آن اختصاص داده شده است.

05:52.390 --> 05:52.840
اما حالا وقتی این کار را انجام می‌دهم می‌بینید که باید کارمند را تغییر دهم.

05:52.840 --> 05:58.270
و سپس باید.

05:58.270 --> 05:59.950
خب، مدیر فعلاً شاکی نیست.

05:59.950 --> 06:06.850
اما وقتی اینجا را تغییر دهم، سپس احتمالاً نیاز خواهیم داشت که مدیر را نیز تغییر دهیم.

06:06.850 --> 06:07.720
پس شما می‌بینید که این باعث بروز انواع خطاها می‌شود.

06:07.720 --> 06:10.450
و در مورد ما این آسان است زیرا ما خودمان کنترل همه چیز را داریم.

06:10.450 --> 06:14.470
ما کلاس شخص، کلاس کارمند و کلاس مدیر را کنترل می‌کنیم.

06:14.470 --> 06:22.780
اما اگر ما تنها کنترل کلاس کارمند را داشته باشیم؟

06:22.780 --> 06:30.130
و حالا ما از این تغییر در کلاس شخص آگاه نبودیم، و ناگهان کد ما دیگر کار نمی‌کند

06:30.130 --> 06:30.820
دیگر.

06:30.820 --> 06:38.650
که به همین دلیل است که گاهی اوقات وقتی به‌روزرسانی‌ها اتفاق می‌افتد، ناگهان افزونه‌هایی که شما استفاده می‌کنید دیگر کار نمی‌کنند

06:38.650 --> 06:44.590
چون انتظار داشتند که یک کلاس به شکلی خاص باشد یا یک تکه کد به شکلی خاص کار کند.

06:44.590 --> 06:46.330
اما با به‌روزرسانی که انجام شده، این تغییر کرده است و ناگهان API تغییر کرده است.

06:46.330 --> 06:51.220
پس به‌طور اساسی، نقاط دسترسی که می‌توانید داده‌ها را از یک وب‌سایت دریافت کنید، به‌عنوان مثال، تغییر کرده است

06:51.220 --> 06:58.330
و ناگهان شما دیگر داده‌ها را دریافت نمی‌کنید و اپلیکیشن شما دیگر هیچ چیزی نمایش نمی‌دهد و بی‌فایده است.

06:58.330 --> 07:03.820
خوب.

07:03.820 --> 07:04.450
و حالا باید بررسی کنید که چه چیزی تغییر کرده است.

07:04.450 --> 07:11.530
و شاید مدارک به‌روزرسانی نشده باشد و هنوز نمی‌دانید که چه چیزی را باید تغییر دهید.

07:11.530 --> 07:15.040
پس شما باید کمی اشکال‌زدایی کنید یا به عمق کد خود فرو بروید.

07:15.040 --> 07:19.630
خوب، پس این فقط برای نشان دادند دلیل اینکه چرا ممکن است دردسر فراهم شود، بود که مجبور به به‌روزرسانی همه چیز باشید.

07:19.630 --> 07:27.280
خوب، پس فکر می‌کنم این باید ایده خوبی به شما داده باشد و چیزهایی برای به خاطر سپردن.

07:27.370 --> 07:35.800
پس زنجیره‌سازی سازنده یعنی سازنده‌ها در کلاس‌های مشتق باید سازنده کلاس پایه مربوطه را فراخوانی کنند تا اطمینان حاصل شود که

07:35.800 --> 07:42.100
سازنده پایه به درستی اولیه‌سازی می‌شود.

07:42.100 --> 07:45.490
سپس ما ترتیب اجرا را داریم.

07:45.490 --> 07:47.560
سازنده کلاس پایه قبل از سازنده کلاس مشتق اجرا می‌شود.

07:47.560 --> 07:52.180
این اطمینان می‌دهد که کلاس پایه به طور کامل اولیه‌سازی شده است قبل از آنکه هر گونه اولیه‌سازی خاص کلاس مشتق انجام شود.

07:52.180 --> 07:57.550
سپس ما اولیه‌سازی سفارشی داریم، بنابراین کلاس مشتق می‌تواند منطق اولیه‌سازی خاص خود را اضافه کند و

07:57.550 --> 08:04.300
پارامترهایی را به کار ببندد که عملکردی را که کلاس پایه ارائه می‌دهد گسترش دهد در حالی که کد اولیه‌سازی مشترک را دوباره استفاده می‌کند.

08:04.300 --> 08:10.960
و سپس ما انعطاف‌پذیری و استفاده مجدد داریم.

08:10.960 --> 08:11.560
پس وراثت سازنده انعطاف‌پذیری را در استفاده مجدد از کد ترویج می‌دهد که به شما اجازه می‌دهد تا سلسله‌مراتب شیء پیچیده بسازید

08:11.560 --> 08:13.870
در حالی که کد تمیز و قابل نگهداری را حفظ می‌کند.

08:13.870 --> 08:19.780
پس می‌توانم بگویم که برای این ویدیو اینجا تمام است.

08:19.780 --> 08:22.870
به زودی در ویدیوی بعدی می‌بینمتان.
```