وراثت در Class Diagram

[اوبالیت به بو]

سلام
وراثت چي جوري در Class Diagram پياده سازي مي شه؟
يه چيزي راجب is-a شنيدم اما نديدم كه چي هست.

[cups_of_java]

سلام
وراثت چي جوري در Class Diagram پياده سازي مي شه؟
يه چيزي راجب is-a شنيدم اما نديدم كه چي هست.

منظورتون از پیاده سازی اینه که چه طوری تشخیص داده میشه و استفاده میشه؟

وراثت به طور کلی یک نوع رابطه Generalization-Specification (تعمیم-تخصیص) هست. رابطه تعمیم (generalization) به این معنی هست که شما یک طبقه/کلاس عمومی تر و یا کلی تر داری. مثلن وقتی شما کلاس حیوان داری میتونی اون رو تعمیم به موجود زنده (موجودی عمومی تر) بدی. (توجه کن که در این رابطه حتمن و حتمن باید هر عنصر از طبقه جزیی در مجموعه طبقه کلی هم وجود داشته باشه! یعنی هر حیوان حتمن جزو موجودات زنده باشد! که اینطور هست پس این رابطه درست است.)
و تخصیص (Specification) هم برعکس حالت قبل، یعنی شما یه طبقه رو به طبقه های جزیی و خاص تر تقسیم کنید. مثلن میشه مواد رو به سه دسته جامدات، مایعات و گازها تقسیم کرد. خب این دسته ها جزیی هستند و هر کدوم جزییات خودشون رو دارن. اما طبق قانون بالا هر سه ماده هستند! ضمنن هر ماده ای رو هم که بگید تو یکی از این 3 دسته جای میگیره و نه تو 2 تا دسته به طور همزمان!

با این توضیحات، به طور خلاصه میشه گفت، وراثت یک نوع رابطه هست که در اون طبقه عمومی رو پدر و طبقه جزیی رو فرزند میگیم. طبیعیست که فرزندان زیر مجموعه هایی از پدران خود هستند و قانون طلایی در این رابطه اینه که:
فرزند ها حتمن باید از جنس پدر باشند!
یا به بیان علمی تر:
شما باید بتونید هر فرزند از هر طبقه که باشه رو با پدر خود عوض کنید! (مثلن هر حیوان میتونه جای یک موجود زنده باشه، هر مایعی ماده هست و ...)
این همون رابطه is-a هست. (Every child is a parent also) روشنه؟

این اصول اولیه و ماهیت استفاده از وراثت در طراحی شی گرا هستش. چیزی که ما به کررات در دنیای خودمون هم می بینیم. همه چیز انواع دارند، ابر نوع دارند، زیر نوع دارند و ...
این باعث میشه خوشبختانه وراثت بسیار ابزار قوی ای در شی گرایی باشه، از طرف دیگه متاسفانه باعث میشه از وراثت در خیلی جاهای دیگه هم استفاده شه!!! یعنی جاهایی که واقعن رابطه هم نوع (is-a) وجود نداشته! (میدونید چرا و چگونه؟) اینجاست که وراثت اون روی خشن خودش رو نشون طرح شما میده! وراثت با همه این قدرت، یک رابطه ایستا و خشک بین پدر و فرزند ها تعریف میکنه. این از انعطاف و تغییر پذیری سیستم کم میکنه. از طرفی وراثت قوی ترین نوع Coupling در سیستم هست! (چه چیزی وابسته تر از پدر و فرزند؟) و همه می دونیم که coupling باید کم باشه و اگر تعداد اتصالات و وابستگی های قوی بالا بره، طرح سخت و خشک میشه و غیر قابل انعطاف!

با این اساس، هر استفاده دیگه ای از وراثت می تونه به ضرر شما در طراحی تموم شه. این استفاده های نا به جا وقتی هستند که رابطه از نوع is-a نباشه در وراثت , اصولن در طراحی تفضیلی رخ میده و نه در تحلیل و یا فاز های اول طراحی... (به همون چرا و چگونه ای که پرسیدم فکر کنید.)

[m.hamidreza]

متاسفانه باعث میشه از وراثت در خیلی جاهای دیگه هم استفاده شه!!! یعنی جاهایی که واقعن رابطه هم نوع (is-a) وجود نداشته!
این استفاده های نا به جا وقتی هستند که رابطه از نوع is-a نباشه در وراثت , اصولن در طراحی تفضیلی رخ میده و نه در تحلیل و یا فاز های اول طراحی... (به همون چرا و چگونه ای که پرسیدم فکر کنید.)

برادرجان یه مثال برای این موضوع مطرح میفرمایید...
ممنون.

[cups_of_java]

برادرجان یه مثال برای این موضوع مطرح میفرمایید...
ممنون.

دوست داشتم اون دوستمون که سوالو پرسیده اول یه نظری می داد بعد... اما خودم یه نمونه بارزش رو میگم:

یکی از امکانات قوی ای که وراثت به ما میده "استفاده مجدد" (reuse) هستش. به طوریکه همه می دونن ساده ترین مدل استفاده مجدد در وراثت اینه که یک متد رو میزاریم تو کلاس پدر و همه فرزندان ازش استفاده می کنن! این موضوع در خیلی از موارد باعث میشه ما بدون اینکه توجه کنیم که آیا رابطه پدر-فرزندی (is-a) اصلن بین این دو کلاس وجود داشته یا نه میایم وراثت ایجاد میکنیم برای اینکه یه سری متد رو reuse کنیم و بین یک سری کلاس تقسیم کنیم.
این موضوع ماهیتن در طراحی اتفاق می افته و زمانی که داریم کد های مربوط به پایگاه داده، یا کد های مربوط واسط گرافیکی و یا کد های مربوط به ساختار های داده و ... رو اضافه می کنیم. در تحلیل این موجودات نیستند و ما فقط به کلاس های دامنه مسئله میپردازیم بنابراین تو دامنه مسئله امکان استفاده اشتباه از وراثت کمتر هست... (راه درست reuse در این حالات چی می تونه باشه؟)
یک مثال دیگه اضافه کردن فریم ورک هاست... تا حالا چند دفعه شده برای اینکه شما یه کلاسی که تو تحلیل داشتین و توش منطق های خودشو داره رو بیارید و از به عنوان فرزند یه کلاسی دیگه توی اون فریم ورک تعریفش کنید تا کدتون توی فریم ورک کار کنه!؟ (بارزترین مثالش EJBها برای جاوا کارهاست. ) این موضوع هم توی طراحی اتفاق می افته و در عمل کاری بوده اشتباه... چون قابلیت تعریف ساختار توارثی برای کلاس شما رو ازتون میگیره (شما از یه کلاس تو فریم ورک وراثت گرفتین و فقط می تونین یک پدر داشته باشین! پس دیگه نمی تونین ساختار خودتون رو گسترش بدین.)
این موضوع هم امروزه توسط اکثر فریم ورک ها در حال حل شدن هست چون به اشتباهشون پی برده اند...