بایگانی

بایگانی دی

عمق وراثت (Depth of Inheritance)

هفته قبل رامین در جلسات باز نرم‌افزاری تبریز در مورد الگوی طراحی Decorator  صحبت می‌کرد. سوالی که توسط تعدادی از دوستان مطرح شد این بود که چرا از وراثت به جای این الگو استفاده نکنیم؟ دلیلی که توسط رامین به آن اشاره شد این بود که رفتار و ویژگی‌های جدید با استفاده از این الگو در زمان اجرا به نمونه کلاس‌ها اضافه می‌شود نه به خود کلاس. در حالیکه با استفاده از وراثت رفتار و ویژگی‌های جدید به زیرکلاس اضافه می‌شود و در نتیجه این ویژگی‌ها به همه نمونه‌های آن افزوده می‌شود.

وراثت در برایر Decorator

وراثت در برایر Decorator

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

عمق وراثت یکی از متریک‌های طراحی شی‌گرا می‌باشد که به این شکل تعریف می شود: “حداکثر فاصله یک گره از گره پدر درخت”. برای نمونه من درخت وراثت را برای کلاس Hidden از فریم‌ورک Asp.NET MVC رسم کردم و همانطوریکه در تصویر مشخص هست عمق این درخت ۴ هست. به یک نکته توجه کنید که در بسیاری از زبانها همه کلاس‌ها از یک کلاس پایه ارث می‌برند حتی اگر به طور صریح در کد شما به آن اشاره نشده باشد. برای نمونه در سی شارپ همه کلاسها از کلاس Object ارث می‌برند پس هر کلاسی که شما ایجاد کنید حداقل دارای عمق یک خواهد بود.

 

عمق وراثت کلاس Hidden

عمق وراثت کلاس Hidden

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

 

حداکثر مقدار قابل قبول برای عمق وراثت چقدر است؟ هیچ مقدار استانداردی برای حداکثر مقدار بهینه عمق وراثت تا بحال اعلام نشده است. مقادیر توصیه شده از ۵ تا ۸ متغییر است. برای نمونه مستندات مایکروسافت ویژوال استودیو مقدار ۵ را پیشنهاد می‌کند در حالیکه برای نمونه در سورس Asp.net MVC که مربوط به خود این شرکت هست عمقی تا هفت را می‌توان مشاهده کرد. شاید دلیلی که نمی‌توان یک حداکثر مقدار بهینه برای این متریک تعیین کرده در متفاوت بودن ماهیت سیستم‌های نرم‌افزاری باشد. برای مثال شاید برای یک فریم‌ورک توسعه وب مقدار ۵، ۶ قابل قبول است در حالیکه برای یک سیستم اتوماسیون اداری این اعداد یک مقدار بزرگ است.

حداکثر عمق کلاس در فریم‌ورک ASP.NET MVC

حداکثر عمق کلاس در فریم‌ورک ASP.NET MVC

من و ابهاماتم از کار حرفه‌ای

اپیزود اول

  • شرایط کاری آنجا که سخت نیست؟
  • هاها، آنجا کار چند هفته‌ای را نوی چند ماه تحویل میدادم. اصلا من همانجا بود که زبانهای ترکی استانبولی و انگلیسی را یاد گرفتم.

اپیزود دوم

  • من کم‌کاری نمی‌کنم، دقیقا به اندازه پولی که به هم می‌دهند کار می‌کنم. پس کار چند روز را تا چند هفته کش می‌دهم.

اپیزود سوم

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

جلسات باز نرم‌افزاری تبریز

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

سه قسمت بالا قسمتی از شنیده‌ها و بحث‌های بود که ما با بعضی از دوستان عزیز داشتیم ولی وقتی من این قطعات و بعضی از گفتگوها دیگر را کنار هم قرار می‌دهم با تناقض و سوال روبرو می‌شوم و پیش خودم فکر کردم شاید با نوشتن و بحث در مقیاس بزرگتر بتوانم به جواب سوالات خود برسم.

دوستی که در قسمت اول به آن اشاره شد در یک شرکت خوب از لحاظ اقتصادی کار می‌کرد و از حقوقی که دریافت می‌کرد راضی بود ولی باز وظیفه‌ای که به عهده‌ش بود را تا حد ممکن عقب می‌انداخت. دوست مثال دوم همان رفتار دوست اول را دارد با این تفاوت که از حقوق دریافتی خود ناراضی هست. آیا با افزایش حقوق نفر دوم می‌توان کارایی آن فرد را در طولانی مدت بالا برد؟ به نظر من شاید فرد دوم کارایی خود را در کوتاه مدت بالا ببرد ولی به احتمال زیاد بعد از مدتی داستان فرد اول برای فرذ دوم نیز تکرار خواهد شد. نظر شما چیست؟

Episode

 خودمختاری! . آدمی حتی از شنیدن کلمه اختیار و آزادی حس خوب پیدا می‌کند چه برسد به داشتنش. این موارد امروزه از محرک‌های اصلی برای انگیزش تیم‌ها و افراد هست. گوگل، فیس‌بوک، تیم‌های چابک، سازمانهای افقی و … یکی از عناصر اصلی که به کارمندان و تیم‍‌های می‌دهند خودمختاری هست. حتی ما سیستمی به نام “محیط کاری نتیجه‌گرا” (ROWE) را داریم که خودمختاری افراطی را توصیه می‌کند. در این سیستم مردم زمانبندی ندارند، هر وقت بخواهند سرکار می‌روند. موظف نیستند سر ساعت خاصی در دفترشان باشند، یا اصلا بروند. اونا فقط باید کارشان را انجام بدهند. چطور این کار را انجام می‌دهند، کجا انجام می‌دهند، کاملن بستگی به خودشان داره. جلسات در این نوع محیط‌ها اختیاری است. و در نهایت بازدهی در همه زمینه‌ها بالا می‌رود.

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

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