උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දක්වන්නේ ඇයි? සෑම ප්‍රවේශයක් සඳහාම ඇති වෙළඳාම් මොනවාද? සංයුතියට වඩා උරුමය තෝරාගත යුත්තේ කවදාද?

පසුකාලීනව වෙනස් කිරීමට පහසු / පහසු බැවින් උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දක්වන්න, නමුත් රචනා-සැමවිටම ප්‍රවේශයක් භාවිතා නොකරන්න. සංයුතිය සමඟ, යැපුම් එන්නත් / සැකසුම් සමඟ මැස්සන්ගේ හැසිරීම වෙනස් කිරීම පහසුය. බොහෝ භාෂාවන් ඔබට එක් වර්ගයකට වඩා ව්‍යුත්පන්න කිරීමට ඉඩ නොදෙන බැවින් උරුමය වඩාත් දෘඩ වේ. එබැවින් ඔබ TypeA වෙතින් ව්‍යුත්පන්න වූ පසු පාත්තයා වැඩි වශයෙන් හෝ අඩු වශයෙන් පිසිනු ලැබේ.

ඉහත සඳහා මගේ අම්ල පරීක්ෂණය:

• TypeA හි සම්පූර්ණ අතුරු මුහුණත (සියලු පොදු ක්‍රම නොඅඩු) නිරාවරණය කිරීමට TypeB ට අවශ්‍යද? උරුමය පෙන්නුම් කරයි .

  • උදා: සෙස්නා බයිප්ලේන් යානයකින් ගුවන් යානයක සම්පූර්ණ අතුරුමුහුණත නිරාවරණය වනු ඇත. එම නිසා එය ගුවන් යානයෙන් ව්‍යුත්පන්න කිරීමට සුදුසු වේ.

• TypeA විසින් නිරාවරණය කරන ලද හැසිරීම් වලින් කොටසක් / කොටසක් පමණක් TypeB ට අවශ්‍යද? සංයුතිය සඳහා අවශ්‍යතාවය දක්වයි.

  • උදා: කුරුල්ලෙකුට අවශ්‍ය වන්නේ ගුවන් යානයක පියාසර හැසිරීම පමණි. මෙම අවස්ථාවේ දී, එය අතුරු මුහුණතක් / පන්තියක් / දෙකම ලෙස උපුටා ගැනීම සහ එය පන්ති දෙකේම සාමාජිකයෙකු බවට පත් කිරීම අර්ථවත් කරයි.

යාවත්කාලීන කිරීම: මගේ පිළිතුරට නැවත පැමිණ ඇති අතර, දැන් බාබරා ලිස්කොව්ගේ ලිස්කොව් ආදේශන මූලධර්මය 'මම මේ වර්ගයෙන් උරුම විය යුතුද?'

A හි අඩංගු ලෙස සිතීම aසම්බන්ධතාවයක් . මෝටර් රථයකට “එන්ජිමක් ඇත, පුද්ගලයෙකුට” නමක් ඇත.

උරුමය ලෙස සිතන්න a සම්බන්ධතාවයක් . මෝටර් රථයක් යනු "වාහනයක්, පුද්ගලයෙකු" යනු "ක්ෂීරපායී යනාදිය" ය.

මෙම ප්‍රවේශය ගැන මම කිසිදු ගෞරවයක් නොගනිමි. මම කෙලින්ම සිට එය රැගෙන සංග්රහයේ සම්පූර්ණ දෙවන සංස්කරණය විසින් ස්ටීව් මැක්කොනෙල් , වගන්තිය 6.3 .

ඔබ වෙනස තේරුම් ගන්නේ නම්, එය පැහැදිලි කිරීම පහසුය.

කාර්ය පටිපාටික කේතය

පංති භාවිතයෙන් තොරව (විශේෂයෙන් PHP5 ට පෙර) PHP මෙයට නිදසුනකි. සියලුම තර්කනයන් කාර්යයන් සමූහයක් තුළ කේතනය කර ඇත. ඔබට උපකාරක කාර්යයන් අඩංගු වෙනත් ලිපිගොනු ඇතුළත් කළ හැකි අතර, කාර්යයන් තුළ දත්ත සම්ප්‍රේෂණය කිරීමෙන් ඔබේ ව්‍යාපාර තර්කනය මෙහෙයවන්න. යෙදුම වර්ධනය වන විට මෙය කළමනාකරණය කිරීම ඉතා අපහසු වේ. PHP5 වැඩි වස්තු නැඹුරු මෝස්තරයක් ලබා දීමෙන් මෙය විසඳීමට උත්සාහ කරයි.

උරුමය

මෙය පන්ති භාවිතය දිරිමත් කරයි. උරුමය යනු OO නිර්මාණයේ මූලධර්ම තුනෙන් එකකි (උරුමය, බහුමාපකය, සංසරණය).

class Person {
   String Title;
   String Name;
   Int Age
}

class Employee : Person {
   Int Salary;
   String Title;
}

මෙය රැකියාවේ උරුමයයි. සේවකයා යනු “පුද්ගලයෙක්” හෝ පුද්ගලයෙකුගෙන් උරුම වූවකි. සියලුම උරුම සම්බන්ධතා "යනු-අ" සම්බන්ධතා ය. සේවකයා විසින් හිමිකම් දේපල පුද්ගලයාගෙන් සෙවනැලි කරයි, එනම් සේවකයා යන්නයි. මාතෘකාව මඟින් සේවකයාට නොව සේවකයාට මාතෘකාව ආපසු ලබා දෙනු ඇත.

සංයුතිය

උරුමය මත සංයුතිය වඩාත් කැමති වේ. ඉතා සරළව කිවහොත් ඔබට ඇත්තේ:

class Person {
   String Title;
   String Name;
   Int Age;

   public Person(String title, String name, String age) {
      this.Title = title;
      this.Name = name;
      this.Age = age;
   }

}

class Employee {
   Int Salary;
   private Person person;

   public Employee(Person p, Int salary) {
       this.person = p;
       this.Salary = salary;
   }
}

Person johnny = new Person ("Mr.", "John", 25);
Employee john = new Employee (johnny, 50000);

සංයුතිය සාමාන්‍යයෙන් "ඇති" හෝ "සම්බන්ධතාවයක්" භාවිතා කරයි. මෙහි සේවක පන්තියට පුද්ගලයෙක් සිටී. එය පුද්ගලයාගෙන් උරුම නොවන අතර ඒ වෙනුවට පුද්ගල වස්තුව එයට ලබා දෙයි, ඒ නිසා එයට “පුද්ගලයෙක්” සිටී.

උරුමය මත සංයුතිය

දැන් ඔබට කළමනාකරු වර්ගයක් සෑදීමට අවශ්‍ය යැයි කියන්න එවිට ඔබ අවසන් වන්නේ:

class Manager : Person, Employee {
   ...
}

මෙම උදාහරණය හොඳින් ක්‍රියාත්මක වනු ඇත, කෙසේ වෙතත්, පුද්ගලයා සහ සේවකයා යන දෙදෙනාම ප්‍රකාශ කළහොත් කුමක් කළ Titleයුතුද? කළමනාකරු. මාතෘකාව "මෙහෙයුම් කළමනාකරු" හෝ "මිස්ටර්" ආපසු ලබා දිය යුතුද? සංයුතිය යටතේ මෙම අවිනිශ්චිතතාව වඩා හොඳින් හසුරුවනු ලැබේ:

Class Manager {
   public string Title;
   public Manager(Person p, Employee e)
   {
      this.Title = e.Title;
   }
}

කළමනාකරු වස්තුව සේවකයෙකු සහ පුද්ගලයෙකු ලෙස රචනා වී ඇත. මාතෘකාව හැසිරීම සේවකයාගෙන් ගනු ලැබේ. මෙම පැහැදිලි සංයුතිය වෙනත් දේ අතර අපැහැදිලි බව ඉවත් කරන අතර ඔබට අඩු දෝෂයන් හමුවනු ඇත.

උරුමය මගින් ලබා දී ඇති සියලු ප්‍රතික්ෂේප කළ නොහැකි ප්‍රතිලාභ සමඟ, එහි අවාසි කිහිපයක් මෙන්න.

උරුමයේ අවාසි:

1. ධාවන වේලාවේදී සුපිරි පංති වලින් උරුම වූ ක්‍රියාත්මක කිරීම ඔබට වෙනස් කළ නොහැක (පැහැදිලිවම උරුමය සම්පාදනය කරන වේලාවේදී අර්ථ දක්වා ඇති නිසා).
2. උරුමය එහි මව් පංතිය ක්‍රියාත්මක කිරීම පිළිබඳ විස්තර සඳහා උප පංතියක් නිරාවරණය කරයි, ඒ නිසා බොහෝ විට කියැවෙන්නේ උරුමය සංවර්‍ධනය බිඳ දමයි (එක් අර්ථයකින් ඔබ සැබවින්ම අවධානය යොමු කළ යුත්තේ අතුරු මුහුණත් කෙරෙහි පමණක් නොව ක්‍රියාත්මක කිරීම පමණක් නොවන බැවින් උප පංති මගින් නැවත භාවිතා කිරීම සැමවිටම කැමති නොවේ).
3. උරුමය විසින් සපයනු ලබන තද බැඳීම, උප පංතියක් ක්‍රියාත්මක කිරීම සුපිරි පංතියක් ක්‍රියාත්මක කිරීම සමඟ බෙහෙවින් බැඳී ඇති අතර මවුපිය ක්‍රියාත්මක කිරීමේ ඕනෑම වෙනසක් උප පංතිය වෙනස් කිරීමට බල කරයි.
4. උප පංති මගින් අධික ලෙස නැවත භාවිතා කිරීමෙන් උරුමය ගොඩගැසීම ඉතා ගැඹුරු හා ව්‍යාකූල විය හැකිය.

අනෙක් අතට, වස්තු සංයුතිය ධාවන වේලාවේදී අර්ථ දැක්වෙන්නේ වෙනත් වස්තූන් වෙත යොමු කිරීම් ලබා ගන්නා වස්තූන් හරහා ය. එවැනි අවස්ථාවකදී මෙම වස්තූන් කිසි විටෙකත් එකිනෙකාගේ ආරක්‍ෂිත දත්ත වෙත ළඟා වීමට නොහැකි වනු ඇත (සංවෘත බිඳීමක් නොමැත) සහ එකිනෙකාගේ අතුරු මුහුණතට ගරු කිරීමට බල කෙරෙනු ඇත. මෙම අවස්ථාවෙහිදී, ක්‍රියාත්මක කිරීමේ පරායත්තතාවයන් උරුමයට වඩා බෙහෙවින් අඩු වනු ඇත.

තවත්, ඉතා ප්‍රායෝගික හේතුවක් නම්, උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දැක්වීම ඔබේ වසම් ආකෘතිය හා සම්බන්ධ වන අතර එය සම්බන්ධතා දත්ත ගබඩාවකට සිතියම් ගත කිරීමයි. SQL ආකෘතියට උරුමය සිතියම් ගත කිරීම ඇත්තෙන්ම දුෂ්කර ය (ඔබ අවසන් වන්නේ සෑම විටම භාවිතා නොකරන තීරු නිර්මාණය කිරීම, අදහස් භාවිතා කිරීම වැනි සියලු ආකාරයේ අනවසර ක්‍රියාමාර්ගයන් සමඟ ය). සමහර ORMLs මෙය සමඟ කටයුතු කිරීමට උත්සාහ කරයි, නමුත් එය සෑම විටම ඉක්මනින් සංකීර්ණ වේ. වගු දෙකක් අතර විදේශීය යතුරු සම්බන්ධතාවයක් හරහා සංයුතිය පහසුවෙන් ආදර්ශනය කළ හැකි නමුත් උරුමය වඩා දුෂ්කර ය.

කෙටියෙන් කිවහොත්, "උරුමයට වඩා සංයුතියට මනාපය" සමඟ මම එකඟ වන අතර, බොහෝ විට මට එය "කොකාකෝලා වලට වඩා අර්තාපල් වලට වැඩි කැමැත්තක් දක්වන්න" වැනි ය. උරුමය සඳහා ස්ථාන සහ සංයුතිය සඳහා ස්ථාන තිබේ. ඔබ වෙනස තේරුම් ගත යුතුය, එවිට මෙම ප්‍රශ්නය අතුරුදහන් වනු ඇත. මට එය සැබවින්ම අදහස් කරන්නේ "ඔබ උරුමය භාවිතා කිරීමට යන්නේ නම් - නැවත සිතන්න, ඔබට සංයුතිය අවශ්‍ය වේ".

ඔබට කෑමට අවශ්‍ය විට කොකා කෝලා වලට වඩා අර්තාපල් ද, පානය කිරීමට අවශ්‍ය විට අර්තාපල් වලට වඩා කොකා කෝලා ද කැමති විය යුතුය.

උප පංතියක් නිර්මාණය කිරීම යනු සුපිරි පන්ති ක්‍රම ඇමතීමට පහසු ක්‍රමයකට වඩා වැඩි යමක් විය යුතුය. උප පංතිය ව්‍යුහාත්මකව හා ක්‍රියාකාරීව සුපිරි පන්තියක් වන විට එය සුපිරි පන්තියක් ලෙස භාවිතා කළ හැකි අතර ඔබ එය භාවිතා කිරීමට යන විට ඔබ උරුමය භාවිතා කළ යුතුය. එය එසේ නොවේ නම් - එය උරුමයක් නොව වෙනත් දෙයක්. සංයුතිය යනු ඔබේ වස්තූන් වෙනත් එකකින් සමන්විත වන විට හෝ ඒවාට යම් සම්බන්ධතාවයක් ඇති විටය.

ඉතින් මට නම් පෙනෙන්නේ යමෙකුට උරුමය හෝ සංයුතිය අවශ්‍ය දැයි නොදන්නේ නම්, සැබෑ ගැටළුව නම් ඔහුට පානය කිරීමට හෝ කෑමට අවශ්‍ය දැයි ඔහු නොදැන සිටීමයි. ඔබගේ ගැටළු වසම ගැන වැඩි දුර සිතන්න, එය වඩා හොඳින් තේරුම් ගන්න.

උරුමය විශේෂයෙන් ක්‍රියා පටිපාටික භූමියෙන් පැමිණීම සිත් ඇදගන්නා සුළු වන අතර එය බොහෝ විට රැවටිලිකාර ලෙස පෙනේ. මම කිව්වේ මට කරන්න තියෙන්නේ මේ ක්‍රියාකාරිත්වය ටිකක් වෙනත් පන්තියකට එකතු කරන්න නේද? හොඳයි, එක් ගැටලුවක් එයයි

උරුමය යනු ඔබට තිබිය හැකි නරකම ආකාරයකි

ආරක්ෂිත සාමාජිකයින්ගේ ස්වරූපයෙන් උප පංති වලට ක්‍රියාත්මක කිරීමේ තොරතුරු නිරාවරණය කිරීමෙන් ඔබේ මූලික පන්තිය සංවෘත කිරීම බිඳ දමයි. මෙය ඔබේ පද්ධතිය දෘඩ හා බිඳෙන සුළු කරයි. කෙසේ වෙතත් වඩාත් ඛේදජනක දෝෂය නම් නව උප පංතිය උරුම දාමයේ සියලු ගමන් මලු සහ මතය ගෙන ඒමයි.

ලිපිය, උරුමය නපුරු ය: ඩේටා ඇනෝටේෂන්ස් මොඩල්බයින්ඩර් හි එපික් ෆේල් , සී # හි මේ සඳහා උදාහරණයක් සපයයි. සංයුතිය භාවිතා කළ යුතු විට උරුමය භාවිතා කිරීම සහ එය නැවත ප්‍රතිනිර්මාණය කළ හැකි ආකාරය එහි දැක්වේ.

මෙහි සතුටුදායක පිළිතුරක් සොයාගත නොහැකි වූ නිසා මම අලුත් එකක් ලිව්වෙමි.

“ උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දක්වන්නේ ඇයි” යන්න තේරුම් ගැනීමට , මෙම කෙටි මෝඩකම තුළ අතහැර දමා ඇති උපකල්පනය නැවත ලබා ගත යුතුය.

උරුමයේ වාසි දෙකක් තිබේ: උප වර්ගීකරණය සහ උප පංතිය

1. උප ටයිප් කිරීම යනු වර්ගයේ (අතුරුමුහුණත්) අත්සනකට අනුකූල වීම, එනම් ඒපීඅයි සමූහයක් වන අතර යමෙකුට අත්සනෙහි කොටසක් අභිබවා බහුඅවයවිකතාව ලබා ගත හැකිය.

2. උප පංතිය යනු ක්‍රමවේදය ක්‍රියාත්මක කිරීම ව්‍යංගයෙන් නැවත භාවිතා කිරීමයි.

මෙම ප්‍රතිලාභ දෙක සමඟ උරුමය කිරීම සඳහා විවිධ අරමුණු දෙකක් ඇත: උප වර්ගීකරණය නැඹුරු සහ කේත නැවත භාවිතා කිරීම නැඹුරු.

කේත නැවත භාවිතා කිරීම එකම අරමුණ නම්, උප පංතිය ඔහුට අවශ්‍ය දේට වඩා වැඩි යමක් ලබා දිය හැකිය, එනම් මව් පන්තියේ සමහර පොදු ක්‍රම ළමා පන්තියට එතරම් තේරුමක් නැත. මෙම අවස්ථාවේ දී, උරුමයට වඩා සංයුතියට කැමති වීම වෙනුවට සංයුතිය ඉල්ලා සිටී. "Is-a" vs. "has-a" සංකල්පයක් පැමිණෙන්නේ ද මෙහිදීය.

එබැවින් උප වර්ගීකරණය අරමුණු කරගත් විට පමණක්, එනම් නව පංතිය පසුව බහුමාමක ආකාරයෙන් භාවිතා කිරීම සඳහා, උරුමය හෝ සංයුතිය තෝරා ගැනීමේ ගැටලුවට අප මුහුණ දෙමු. සාකච්ඡාවට භාජනය වූ කෙටි කළ මෝඩකම තුළ මඟ හැරෙන උපකල්පනය මෙයයි.

උප වර්ගය යනු වර්ගයේ අත්සනකට අනුකූල වීමයි, මෙයින් අදහස් කරන්නේ සංයුතියට සෑම විටම ඒපීඅයි වල අඩු ප්‍රමාණයක් නිරාවරණය කළ යුතු බවයි. දැන් වෙළඳ ලකුණු ආරම්භ වන්නේ:

1. අභිමතාර්ථය ඉක්මවා නොගියහොත් සරල කේත නැවත භාවිතා කිරීමක් සපයන අතර සංයුතියට සෑම API එකක්ම නැවත කේතගත කළ යුතුය, එය සරල නියෝජිත පිරිසකගේ කාර්යයක් වුවද.

2. උරුමය සෘජු විවෘත පුනරාවර්තනයක් සපයයි අභ්‍යන්තර බහුමාමක වෙබ් අඩවිය හරහාthis , එනම් පොදු හෝ පෞද්ගලික ( අධෛර්යමත් වුවද ) වෙනත් සාමාජික ශ්‍රිතයක අතිච්ඡාදනය කිරීමේ ක්‍රමය (හෝ ටයිප් කිරීම ). විවෘත පුනරාවර්තනය සංයුතිය හරහා අනුකරණය කළ හැකි නමුත් එයට අමතර වෑයමක් අවශ්‍ය වන අතර සෑම විටම ශක්‍ය නොවිය හැකිය (?). අනුපිටපත් ප්‍රශ්නයකට මෙම පිළිතුර සමාන දෙයක් කථා කරයි.

3. උරුමය මඟින් ආරක්ෂිත සාමාජිකයින් නිරාවරණය වේ. මෙය මව් පංතියේ වටපිටාව බිඳ දමයි, උප පංතිය භාවිතා කරන්නේ නම්, දරුවා සහ එහි මවුපියන් අතර තවත් යැපීමක් හඳුන්වා දෙනු ලැබේ.

4. සංයුතියේ පාලනයේ ප්‍රතිලෝමයේ යෝග්‍යතාවයක් ඇති අතර, එහි පරායත්තතාවය ගතිකව එන්නත් කළ හැකිය, සැරසිලි රටාව සහ ප්‍රොක්සි රටාවෙහි පෙන්වා ඇත .

5. සංයුතියට සංයුක්ත -නැඹුරු වැඩසටහන්කරණයේ වාසිය ඇත , එනම් සංයුක්ත රටාව වැනි ආකාරයකින් ක්‍රියා කිරීම .

6. සංයුතිය වහාම අතුරු මුහුණතකට ක්‍රමලේඛනය අනුගමනය කරයි .

7. සංයුතියට පහසු බහු උරුමයේ වාසිය ඇත .

ඉහත වෙළඳ ගනුදෙනු මනසේ තබාගෙන, අපි උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දක්වමු . තදින් සම්බන්ධිත පංති සඳහා, එනම් ව්‍යංග කේත නැවත භාවිතා කිරීම සැබවින්ම ප්‍රතිලාභ ලබා දෙන විට හෝ විවෘත පුනරාවර්තනයේ ඉන්ද්‍රජාලික බලය අපේක්ෂා කරන විට, උරුමය තේරීම වේ.

ජාවා හෝ සී # හි, වස්තුවක් ක්ෂණික වූ පසු එහි වර්ගය වෙනස් කළ නොහැක.

එබැවින්, ඔබේ වස්තුව වෙනත් වස්තුවක් ලෙස පෙනී සිටීමට හෝ වස්තු තත්වයක් හෝ කොන්දේසි අනුව වෙනස් ලෙස හැසිරීමට අවශ්‍ය නම්, සංයුතිය භාවිතා කරන්න : රාජ්‍ය හා උපාය මාර්ග සැලසුම් රටා වෙත යොමු වන්න .

වස්තුව එකම වර්ගයේ විය යුතු නම්, උරුමය භාවිතා කරන්න හෝ අතුරු මුහුණත් ක්‍රියාත්මක කරන්න.

පුද්ගලිකව මම උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දැක්වීමට ඉගෙන ගතිමි. සංයුතිය සමඟ ඔබට විසඳිය නොහැකි උරුමය සමඟ ඔබට විසඳිය හැකි ක්‍රමලේඛ ගැටළුවක් නොමැත; සමහර අවස්ථාවලදී ඔබට අතුරුමුහුණත් (ජාවා) හෝ ප්‍රොටෝකෝල (Obj-C) භාවිතා කිරීමට සිදුවනු ඇත. C ++ එවැනි දෙයක් නොදන්නා බැවින්, ඔබට වියුක්ත පාදක පන්ති භාවිතා කිරීමට සිදුවනු ඇත, එයින් අදහස් කරන්නේ ඔබට C ++ හි උරුමය මුළුමනින්ම ඉවත් කළ නොහැකි බවයි.

සංයුතිය බොහෝ විට වඩා තාර්කික ය, එය වඩා හොඳ සාරාංශයක්, වඩා හොඳ සංවර්‍ධනයක්, වඩා හොඳ කේත නැවත භාවිතා කිරීමක් (විශේෂයෙන් ඉතා විශාල ව්‍යාපෘති වල) සපයන අතර ඔබේ කේතයේ ඕනෑම තැනක හුදකලා වෙනසක් සිදු කළ පමණින් දුරින් කිසිවක් කැඩීමට ඇති ඉඩකඩ අඩුය. බොහෝ විට සාරාංශගත කර ඇති " තනි වගකීම් මූලධර්මය " පිළිගැනීමට එය පහසු කරයි, " පන්තියක් වෙනස් වීමට කිසි විටෙකත් එකකට වඩා හේතු නොවිය යුතුය. ", එයින් අදහස් කරන්නේ සෑම පන්තියක්ම නිශ්චිත අරමුණක් සඳහා පවතින බවත් එය කළ යුතු බවත් ය එහි අරමුණට කෙලින්ම සම්බන්ධ වන ක්‍රම පමණක් ඇත. ඉතා නොගැඹුරු උරුමයක් ඇති ගසක් තිබීම ඔබේ ව්‍යාපෘතිය සැබවින්ම විශාල වීමට පටන් ගත් විට පවා දළ විශ්ලේෂණය තබා ගැනීම පහසු කරයි. බොහෝ අය සිතන්නේ උරුමය අපේ සැබෑ ලෝකය නියෝජනය කරන බවයිහොඳයි, නමුත් එය සත්‍ය නොවේ. සැබෑ ලෝකය උරුමයට වඩා බොහෝ සංයුතිය භාවිතා කරයි. ඔබේ අතේ තබා ගත හැකි සෑම සැබෑ ලෝක වස්තුවක්ම සෑදී ඇත්තේ වෙනත් කුඩා කුඩා ලෝක වස්තූන්ගෙනි.

සංයුතියේ අවාසි ඇත. ඔබ උරුමය මුළුමනින්ම මඟ හැර සංයුතිය කෙරෙහි පමණක් අවධානය යොමු කරන්නේ නම්, ඔබ බොහෝ විට උරුමය භාවිතා කර ඇත්නම් අවශ්‍ය නොවූ අමතර කේත රේඛා කිහිපයක් ලිවීමට සිදුවන බව ඔබට පෙනෙනු ඇත. ඔබට සමහර විට නැවත නැවත කිරීමට බල කෙරෙන අතර මෙය උල්ලං lates නය කරයි DRY මූලධර්මය උල්ලං lates නය(DRY = ඔබම නැවත කියන්න එපා). සංයුතියට බොහෝ විට නියෝජිතයින් අවශ්‍ය වන අතර ක්‍රමයක් යනු මෙම ඇමතුම වටා වෙනත් කේතයක් නොමැති වෙනත් වස්තුවක තවත් ක්‍රමයක් ඇමතීමයි. එවැනි "ද්විත්ව ක්‍රම ඇමතුම්" (එය පහසුවෙන් ත්‍රිත්ව හෝ හතර ගුණයකින් යුත් ඇමතුම් දක්වා විහිදෙන අතර ඊට වඩා දුරින්) උරුමයට වඩා නරක ක්‍රියාකාරිත්වයක් ඇත, එහිදී ඔබට ඔබේ දෙමව්පියන්ගේ ක්‍රමවේදයක් උරුම වේ. උරුම වූ ක්‍රමයක් ඇමතීම උරුම නොවන එකක් ඇමතීමට සමානව වේගවත් විය හැකිය, නැතහොත් එය තරමක් මන්දගාමී විය හැකිය, නමුත් සාමාන්‍යයෙන් අඛණ්ඩ ක්‍රම ඇමතුම් දෙකකට වඩා වේගවත් වේ.

බොහෝ OO භාෂාවන් බහු උරුමයකට ඉඩ නොදෙන බව ඔබ දැක ඇති. බහුවිධ උරුමයන් ඔබට සැබවින්ම යමක් මිලට ගත හැකි අවස්ථා කිහිපයක් තිබියදීත්, ඒවා නීතියට වඩා ව්‍යතිරේකයකි. "බහු උරුමය මෙම ගැටළුව විසඳීම සඳහා ඇත්තෙන්ම සිසිල් අංගයක් වනු ඇතැයි" ඔබ සිතන තත්වයකට ඔබ පිවිසෙන සෑම විටම, ඔබ සාමාන්‍යයෙන් උරුමය ගැන නැවත සිතා බැලිය යුතු ස්ථානයක සිටී, එයට අමතර කේත රේඛා කිහිපයක් පවා අවශ්‍ය විය හැකිය. , සංයුතිය මත පදනම් වූ විසඳුමක් සාමාන්‍යයෙන් වඩා අලංකාර, නම්‍යශීලී සහ අනාගත සාක්‍ෂි වනු ඇත.

උරුමය ඇත්තෙන්ම සිසිල් ලක්ෂණයකි, නමුත් එය පසුගිය වසර කිහිපය තුළ අධික ලෙස භාවිතා කර ඇති බවට මම බිය වෙමි. නියපොතු, ඉස්කුරුප්පු ඇණ හෝ සමහර විට සම්පූර්ණයෙන්ම වෙනස් දෙයක් වුවද, උරුමය සියල්ලටම ඇණ ගැසිය හැකි එකම මිටියක් ලෙස මිනිසුන් සැලකූහ.

උරුමයට වඩා සංයුතියට වැඩි කැමැත්තක් දක්වන්නේ ඇයි?

වෙනත් පිළිතුරු බලන්න.

ඔබට උරුමය භාවිතා කළ හැක්කේ කවදාද?

පහත දැක්වෙන වාක්‍යය සත්‍ය වූ විට Barපන්තියකට පන්තියක් උරුම කර ගත හැකි බව බොහෝ විට කියනු Fooලැබේ:

1. බාර්එකක් යනු මෝඩයෙකි

අවාසනාවට, ඉහත පරීක්ෂණය පමණක් විශ්වාසදායක නොවේ. ඒ වෙනුවට පහත සඳහන් දෑ භාවිතා කරන්න:

1. බාර්එකක් යනු මෝඩයෙකි, සහ
2. මෝඩයන්ට කළ හැකි සෑම දෙයක්ම බාර් වලට කළ හැකිය.

සියල්ල පළමු ටෙස්ට් වගකීම getters ක Fooපසුබිම අර්ථයෙන් Barඅතර පැවැත්වෙන දෙවන ටෙස්ට් ක්රිකට් තරඟයේ සහතික සියල්ල කරයි අතර, (= හවුල් ලක්ෂණ) ස්ථානගත වන්නන් ක Fooදී සිදු අර්ථයෙන් Bar(= හවුල් ක්රියාකාරිත්වය).

උදාහරණ 1: බල්ලා -> සත්ව

බල්ලෙක් සතෙකු වන අතර බල්ලන්ට සතුන්ට කළ හැකි සෑම දෙයක්ම කළ හැකිය (හුස්ම ගැනීම, මිය යාම ආදිය). එබැවින් පන්තියට උරුම විය Dog හැකියAnimal .

උදාහරණ 2: කවය - / -> ඉලිප්ස

රවුමක් යනු ඉලිප්සයකි, නමුත් රවුම් වලට ඉලිප්සයට කළ හැකි සියල්ල කළ නොහැක. උදාහරණයක් ලෙස, රවුම් දිගු කළ නොහැකි අතර ඉලිප්සාකාරයට හැකිය. එබැවින් පන්තියට උරුම Circle විය නොහැකEllipse .

මෙය රවුම-එලිප්ස් ගැටළුව ලෙස හැඳින්වේ , එය ඇත්ත වශයෙන්ම ගැටළුවක් නොවේ, උරුමය ලැබිය හැකි යැයි නිගමනය කිරීමට පළමු පරීක්ෂණයෙන් පමණක් ප්‍රමාණවත් නොවන බවට පැහැදිලි සාක්ෂියකි. විශේෂයෙන්, මෙම උදාහරණයෙන් ඉස්මතු වන්නේ ව්‍යුත්පන්න කරන ලද පංති මූලික පන්තිවල ක්‍රියාකාරිත්වය දීර් extend කළ යුතු බවත් එය කිසි විටෙකත් සීමා නොකරන බවත්ය. එසේ නොමැති නම්, මූලික පන්තිය බහුමාමක ලෙස භාවිතා කළ නොහැක.

ඔබ උරුමය භාවිතා කළ යුත්තේ කවදාද?

ඔබ පවා නම් හැකි උරුමයක් භාවිතා ඉන් අදහස් කරන්නේ නැහැ ඔබ කළ යුත්තේ : සංයුතිය භාවිතා සෑම විටම විකල්පයක් නොවේ. උරුමය යනු ව්‍යංග කේත නැවත භාවිතා කිරීමට සහ ගතික යැවීමට ඉඩ දෙන ප්‍රබල මෙවලමකි, නමුත් එය අවාසි කිහිපයක් සමඟ පැමිණේ, එබැවින් සංයුතිය බොහෝ විට වඩාත් කැමති වේ. උරුමය සහ සංයුතිය අතර ඇති වෙළඳාම පැහැදිලිව පෙනෙන්නට නැති අතර, මගේ මතය අනුව lcn හි පිළිතුරෙන් වඩාත් හොඳින් පැහැදිලි කර ඇත .

නියමාකාර නීතියක් ලෙස, බහුමාමක භාවිතය ඉතා සුලභ වනු ඇතැයි අපේක්ෂා කරන විට සංයුතියට වඩා උරුමය තෝරා ගැනීමට මම නැඹුරු වෙමි, එම අවස්ථාවේ දී ගතික යැවීමේ බලය වඩාත් කියවිය හැකි සහ අලංකාර API වෙත යොමු විය හැකිය. නිදසුනක් ලෙස, WidgetGUI රාමුවල බහුමාමක පංතියක් හෝ NodeXML පුස්තකාලවල බහුමාමක පංතියක් තිබීම මඟින් සංයුතිය මත පදනම් වූ විසඳුමක් සමඟ ඔබට ඇති දෙයට වඩා කියවිය හැකි සහ භාවිතා කළ හැකි API එකක් ලබා ගැනීමට ඉඩ ලබා දේ.

ලිස්කොව් ආදේශන මූලධර්මය

ඔබ දන්නා පරිදි, උරුමය ලබා ගත හැකිද යන්න තීරණය කිරීම සඳහා භාවිතා කරන තවත් ක්‍රමයක් ලිස්කොව් ආදේශන මූලධර්මය ලෙස හැඳින්වේ :

පාදක පංති වෙත යොමු කිරීම් හෝ යොමු කිරීම් භාවිතා කරන කාර්යයන් නොදැන ව්‍යුත්පන්න පංතිවල වස්තු භාවිතා කළ යුතුය

අත්යවශ්යයෙන්ම, මෙයින් අදහස් කරන්නේ මූලික පංතිය බහුඅවයවික වශයෙන් භාවිතා කළ හැකි නම් උරුමය ලබා ගත හැකි බවයි, එය අපගේ පරීක්ෂණයට සමාන යැයි මම විශ්වාස කරමි "බාර්එකක් මෝඩයෙක් වන අතර බාර්වලට ෆූස්ට කළ හැකි සියල්ල කළ හැකිය".

මගේ සාමාන්‍ය නියමය: උරුමය භාවිතා කිරීමට පෙර, සංයුතිය වඩාත් අර්ථවත් දැයි සලකා බලන්න.

හේතුව: උප පංතිය යනු සාමාන්‍යයෙන් වඩාත් සංකීර්ණත්වය හා සම්බන්ධතාවයයි, එනම් වැරදි සිදු නොවී වෙනස් කිරීමට, නඩත්තු කිරීමට හා පරිමාණය කිරීමට අපහසුය.

සූර්යයාගේ ටිම් බෝඩ්රෝ වෙතින් වඩාත් සම්පූර්ණ හා සංයුක්ත පිළිතුරක් :

මා දකින පරිදි උරුමය භාවිතා කිරීමේ පොදු ගැටළු:

• අහිංසක ක්‍රියාවන්ට අනපේක්ෂිත ප්‍රති results ල ලැබිය හැකිය - මෙයට හොඳම උදාහරණය වන්නේ උප පංති නිදර්ශන ක්ෂේත්‍ර ආරම්භ කිරීමට පෙර සුපිරි පන්තියේ ඉදිකිරීම්කරු වෙතින් ඉක්මවා යා හැකි ක්‍රම වෙත කැඳවීමයි. පරිපූර්ණ ලෝකයක, කිසිවෙකු කිසි විටෙකත් එසේ නොකරනු ඇත. මෙය පරිපූර්ණ ලෝකයක් නොවේ.
• ක්‍රම ඇමතුම් අනුපිළිවෙල ගැන උපකල්පන කිරීමට උප පංතිකරුවන්ට එය වැරදි පෙළඹවීම් ලබා දෙන අතර කාලයත් සමඟ සුපිරි පන්තිය පරිණාමය වුවහොත් එවැනි උපකල්පන ස්ථාවර නොවනු ඇත. මෙයද බලන්නමගේ ටෝස්ටර් සහ කෝපි පෝට් ප්‍රතිසම .
• පන්ති බර වැඩියි - ඔබේ සුපිරි පන්තිය එහි ඉදිකිරීම්කරු තුළ කරන්නේ කුමක්ද යන්න හෝ එය කොපමණ මතකයක් භාවිතා කිරීමට යන්නේ දැයි ඔබ නොදනී. එබැවින් අහිංසක සැහැල්ලු වස්තුවක් තැනීම ඔබ සිතනවාට වඩා බෙහෙවින් මිල අධික විය හැකි අතර සුපිරි පන්තිය පරිණාමය වුවහොත් කාලයත් සමඟ මෙය වෙනස් විය හැකිය
• එය උප පංති පිපිරීමක් දිරිමත් කරයි . පන්ති පැටවීම සඳහා කාලය වැය වේ, වැඩි පන්ති සඳහා මතකය වැය වේ. ඔබ නෙට්බීන්ස් පරිමාණයෙන් යෙදුමක් සමඟ ගනුදෙනු කරන තුරු මෙය ගැටළුවක් නොවන නමුත්, එහිදී අපට සැබෑ ගැටළු ඇති විය, උදාහරණයක් ලෙස මෙනු මන්දගාමී වීම නිසා මෙනුවක පළමු දර්ශනය දැවැන්ත පන්ති පැටවීමක් ඇති කළේය. අපි මෙය වඩාත් ප්‍රකාශන වාක්‍ය ඛණ්ඩ සහ වෙනත් ශිල්පීය ක්‍රම වෙත යොමු කිරීමෙන් එය නිවැරදි කළෙමු.
• එය පසුව දේවල් වෙනස් කිරීම දුෂ්කර කරයි - ඔබ පංතියක් ප්‍රසිද්ධ කර තිබේ නම්, සුපිරි පන්තිය මාරු කිරීම උප පංති බිඳ දමනු ඇත - එය තේරීමක් වන අතර, ඔබ කේතය ප්‍රසිද්ධ කළ පසු ඔබ විවාහ වී ඇත. එබැවින් ඔබ ඔබේ සුපිරි පන්තියට සැබෑ ක්‍රියාකාරිත්වය වෙනස් නොකරන්නේ නම්, ඔබට අවශ්‍ය දේ දිගු කරනවාට වඩා ඔබ භාවිතා කරන්නේ නම් පසුව දේවල් වෙනස් කිරීමට ඔබට වැඩි නිදහසක් ලැබේ. උදාහරණයක් ලෙස, JPanel උප කාණ්ඩය ගන්න - මෙය සාමාන්‍යයෙන් වැරදියි; උප පංතිය කොතැනක හෝ පොදු නම්, එම තීරණය නැවත බැලීමට ඔබට කිසි විටෙකත් අවස්ථාවක් නොලැබේ. එය JComponent getThePanel () ලෙස ප්‍රවේශ වී ඇත්නම්, ඔබට තවමත් එය කළ හැකිය (ඉඟිය: ඔබේ API ලෙස සංරචක සඳහා ආකෘති නිරාවරණය කරන්න).
• වස්තු ධූරාවලිය පරිමාණය නොකෙරේ (නැතහොත් ඒවා පසුව පරිමාණයට පත් කිරීම ඉදිරි සැලසුම් කිරීමට වඩා දුෂ්කර ය) - මෙය සම්භාව්‍ය “ඕනෑවට වඩා ස්ථර” ගැටළුවයි. මම පහතට යන්නෙමි, සහ AskTheOracle රටාව එය විසඳන්නේ කෙසේද (එය OOP පිරිසිදු කරන්නන් අමනාප කළ හැකි වුවද).

...

ඔබ ලුණු ධාන්‍යයක් සමඟ ගත හැකි උරුමය සඳහා ඔබ ඉඩ දෙන්නේ නම් කුමක් කළ යුතුද යන්න මා විසින් ගනු ලැබේ:

• නියතයන් හැර වෙනත් කිසිදු ක්ෂේත්‍රයක් නිරාවරණය නොකරන්න
• ක්‍රම වියුක්ත හෝ අවසාන විය යුතුය
• සුපිරි පන්තියේ ඉදිකිරීම්කරුගෙන් කිසිදු ක්‍රමයක් අමතන්න

...

මේ සියල්ල විශාල ව්‍යාපෘතිවලට වඩා කුඩා ව්‍යාපෘති සඳහා අඩු වන අතර පොදු පන්තිවලට වඩා පෞද්ගලික පන්ති සඳහා අඩු වේ

උරුමය ඉතා බලවත් ය, නමුත් ඔබට එය බල කළ නොහැක (බලන්න: රවුම්-ඉලිප්සාකාර ගැටළුව ). සත්‍ය "යනු" උප ප්‍රභේද සම්බන්ධතාවයක් පිළිබඳව ඔබට සැබවින්ම විශ්වාස කළ නොහැකි නම්, සංයුතිය සමඟ යෑම වඩාත් සුදුසුය.

ගුවන් යානයකට ඇත්තේ කොටස් දෙකක් පමණක් යැයි සිතමු: එන්ජිමක් සහ පියාපත්.
එවිට ගුවන් යානා පන්තියක් සැලසුම් කිරීමට ක්‍රම දෙකක් තිබේ.

Class Aircraft extends Engine{
  var wings;
}

දැන් ඔබේ ගුවන් යානය ස්ථාවර පියාපත් සහිතව ආරම්භ
කර මැස්සන්ගේ භ්‍රමණ පියාපත් ලෙස වෙනස් කළ හැකිය . එය අත්‍යවශ්‍යයෙන්ම
පියාපත් සහිත එන්ජිමකි. නමුත් මට
පියාසර කරන එන්ජිම වෙනස් කිරීමට අවශ්‍ය නම් කුමක් කළ යුතුද?

එක්කෝ මූලික පන්තිය Engineඑහි
ගුණාංග වෙනස් කිරීම සඳහා විකෘතියක් නිරාවරණය කරයි , නැතහොත් මම මෙසේ ප්‍රතිනිර්මාණය කරමි Aircraft:

Class Aircraft {
  var wings;
  var engine;
}

දැන්, මට මගේ එන්ජිම මැස්සා වෙනුවට ආදේශ කළ හැකිය.

උරුමය උප පංතියක් සහ සුපිරි පන්තියක් අතර ශක්තිමත් සම්බන්ධතාවයක් ඇති කරයි; උප පංතිය සුපිරි පන්තියේ ක්‍රියාත්මක කිරීමේ තොරතුරු දැන සිටිය යුතුය. සුපිරි පංතිය නිර්මාණය කිරීම වඩා දුෂ්කර ය, එය දිගු කළ හැකි ආකාරය ගැන සිතා බැලිය යුතු විට. ඔබ පන්ති ආක්‍රමණ ප්‍රවේශමෙන් ලේඛනගත කළ යුතු අතර, අභිබවා යා හැකි වෙනත් ක්‍රම අභ්‍යන්තරව භාවිතා කරන ආකාරය සඳහන් කරන්න.

ධූරාවලිය සැබවින්ම සම්බන්ධතාවයක් නම්, උරුමය සමහර විට ප්‍රයෝජනවත් වේ. එය විවෘත-සංවෘත මූලධර්මයට සම්බන්ධ වන අතර, එහි සඳහන් වන්නේ වෙනස් කිරීම සඳහා පන්ති වසා දැමිය යුතු නමුත් දීර්. කිරීමට විවෘත බවය. එමගින් ඔබට බහුමාපකය තිබිය හැකිය; සුපිරි වර්ගය සහ එහි ක්‍රම සමඟ කටයුතු කරන සාමාන්‍ය ක්‍රමයක් තිබීම, නමුත් ගතික යැවීම හරහා උප පංතියේ ක්‍රමය ක්‍රියාත්මක වේ. මෙය නම්‍යශීලී වන අතර මෘදුකාංගයේ අත්‍යවශ්‍ය වන (ක්‍රියාත්මක කිරීමේ තොරතුරු ගැන අඩුවෙන් දැන ගැනීමට) උදාසීනත්වය නිර්මාණය කිරීමට උපකාරී වේ.

පංති අතර දැඩි පරායත්තතාවයන් සහිතව, උරුමය පහසුවෙන් භාවිතා කළ හැකි අතර අතිරේක සංකීර්ණතාවයක් ඇති කරයි. ස්ථර සහ ගතික තේරීම් ක්‍රම නිසා වැඩසටහනක් ක්‍රියාත්මක කිරීමේදී කුමක් සිදුවේද යන්න තේරුම් ගැනීම දුෂ්කර වේ.

පෙරනිමියෙන් රචනා කිරීම භාවිතා කිරීමට මම යෝජනා කරමි. එය වඩාත් මොඩියුලය වන අතර ප්‍රමාද බන්ධනයේ වාසිය ලබා දෙයි (ඔබට සං component ටකය ගතිකව වෙනස් කළ හැකිය). එසේම දේවල් වෙන වෙනම පරීක්ෂා කිරීම පහසුය. ඔබට පන්තියකින් ක්‍රමයක් භාවිතා කිරීමට අවශ්‍ය නම්, ඔබට කිසියම් ආකාරයක වීමට බල කෙරෙන්නේ නැත (ලිස්කොව් ආදේශන මූලධර්මය).

පන්ති නිර්මාණයේ බොබ් මාමාගේ SOLID මූලධර්මවල ඇති ලිස්කොව් ආදේශන මූලධර්මය දෙස බැලිය යුතුය. :)

ඔබට "පිටපත් කිරීමට" / මූලික පන්තියේ API හෙළි කිරීමට අවශ්‍ය වූ විට, ඔබ උරුමය භාවිතා කරයි. ඔබට අවශ්‍ය වන්නේ "පිටපත් කිරීම" පමණි, නියෝජිත කණ්ඩායම භාවිතා කරන්න.

මේ සඳහා එක් උදාහරණයක්: ඔබට ලැයිස්තුවෙන් පිටත තොගයක් සෑදීමට අවශ්‍යයි. තොගයට ඇත්තේ පොප්, තල්ලු සහ බැලීම් පමණි. ඔබට තල්ලුවක තල්ලු_ ආපසු, තල්ලු_ පෙරමුණ, ඉවත් කිරීම සහ වෙනත් ආකාරයේ ක්‍රියාකාරිත්වයක් අවශ්‍ය නොවන බැවින් ඔබ උරුමය භාවිතා නොකළ යුතුය.

මෙම ක්‍රම දෙක එකට හොඳින් ජීවත් විය හැකි අතර ඇත්ත වශයෙන්ම එකිනෙකාට සහයෝගය දක්වයි.

සංයුතිය එය මොඩියුලය වාදනය කරයි: ඔබ මව් පන්තියට සමාන අතුරු මුහුණතක් සාදයි, නව වස්තුවක් සාදන්න සහ එයට ඇමතුම් ලබා දෙන්න. මෙම වස්තූන් එකිනෙකා ගැන දැන ගැනීමට අවශ්‍ය නොවන්නේ නම්, එය තරමක් ආරක්ෂිත සහ සංයුතිය භාවිතා කිරීම පහසුය. මෙහි බොහෝ හැකියාවන් ඇත.

කෙසේ වෙතත්, කිසියම් හේතුවක් නිසා මව් පන්තියට අද්දැකීම් අඩු ක්‍රමලේඛකයෙකු සඳහා "ළමා පන්තිය" විසින් සපයනු ලබන කාර්යයන් වෙත ප්‍රවේශ වීමට අවශ්‍ය නම් එය උරුමය භාවිතා කිරීමට හොඳ ස්ථානයක් සේ පෙනේ. මව් පංතියට එය තමන්ගේම වියුක්ත "foo ()" ලෙස හැඳින්විය හැකි අතර එය උප පංතිය විසින් නැවත ලියනු ලැබේ, එවිට එය වියුක්ත පදනමට අගය ලබා දිය හැකිය.

එය හොඳ අදහසක් සේ පෙනේ, නමුත් බොහෝ අවස්ථාවන්හීදී පන්තියට නව පංතියක් උරුම කර ගැනීමට වඩා foo () (හෝ අතින් ලබා දී ඇති අගය (අතින් අතින් ලබා දී ඇති අගය) නියම කරන වස්තුවක් ලබා දීම වඩා හොඳය. නියම කළ යුතු foo () ශ්‍රිතය.

මන්ද?

උරුමය යනු තොරතුරු ගෙනයාමේ දුර්වල ක්‍රමයකි .

සංයුතියට මෙහි සැබෑ මායිමක් ඇත: සම්බන්ධතාවය ආපසු හැරවිය හැකිය: "මව් පංතිය" හෝ "වියුක්ත සේවකයා" හට කිසියම් අතුරු මුහුණතක් ක්‍රියාත්මක කරන විශේෂිත "ළමා" වස්තු එක්රැස් කළ හැකිය + ඕනෑම දරුවෙකු වෙනත් ඕනෑම දෙමාපියෙකු තුළ සැකසිය හැකිය, එය පිළිගනී එය වර්ගය . තවද ඕනෑම වස්තු සංඛ්‍යාවක් තිබිය හැකිය, නිදසුනක් ලෙස MergeSort හෝ QuickSort මගින් වියුක්ත සංසන්දනය-අතුරු මුහුණතක් ක්‍රියාත්මක කරන ඕනෑම වස්තු ලැයිස්තුවක් වර්ග කළ හැකිය. නැතහොත් වෙනත් ආකාරයකින් කිවහොත්: "foo ()" ක්‍රියාත්මක කරන ඕනෑම වස්තු සමූහයකට සහ "foo ()" ඇති වස්තූන් භාවිතා කළ හැකි වෙනත් වස්තු සමූහයකට එකට සෙල්ලම් කළ හැකිය.

උරුමය භාවිතා කිරීමට සැබෑ හේතු තුනක් ගැන මට සිතිය හැකිය:

1. ඔබට එකම අතුරු මුහුණතක් සහිත පන්ති රාශියක් ඇති අතර ඒවා ලිවීමට කාලය ඉතිරි කර ගැනීමට ඔබට අවශ්‍යය
2. එක් එක් වස්තුව සඳහා ඔබ එකම මූලික පන්තිය භාවිතා කළ යුතුය
3. ඔබට පුද්ගලික විචල්යයන් වෙනස් කිරීමට අවශ්ය වන අතර එය ඕනෑම අවස්ථාවක ප්රසිද්ධ විය නොහැක

මේවා සත්‍ය නම්, බොහෝ විට උරුමය භාවිතා කිරීම අවශ්‍ය වේ.

හේතුව 1 භාවිතා කිරීමේදී නරක දෙයක් නැත, ඔබේ වස්තූන් මත interface න අතුරු මුහුණතක් තිබීම ඉතා හොඳ දෙයකි. මෙය සංයුතිය භාවිතයෙන් හෝ උරුමයෙන් කළ හැකිය, ගැටළුවක් නැත - මෙම අතුරුමුහුණත සරල නම් සහ වෙනස් නොවේ නම්. සාමාන්‍යයෙන් උරුමය මෙහි බෙහෙවින් is ලදායී වේ.

හේතුව අංක 2 නම් එය ටිකක් උපක්‍රමශීලී වේ. ඔබට ඇත්ත වශයෙන්ම අවශ්‍ය වන්නේ එකම මූලික පන්තිය පමණක්ද? පොදුවේ ගත් කල, එකම මූලික පංතිය භාවිතා කිරීම පමණක් ප්‍රමාණවත් නොවේ, නමුත් එය ඔබේ රාමුවේ අවශ්‍යතාවයක් විය හැකිය.

කෙසේ වෙතත්, ඔබට පුද්ගලික විචල්යයන් වන 3 වන අවස්ථාව භාවිතා කිරීමට අවශ්ය නම්, එවිට ඔබට කරදරයක් විය හැකිය. ඔබ ගෝලීය විචල්‍යයන් අනාරක්‍ෂිත යැයි සලකන්නේ නම්, පුද්ගලික විචල්‍යයන් වෙත ප්‍රවේශය ලබා ගැනීම සඳහා උරුමය භාවිතා කිරීමද අනාරක්‍ෂිත යැයි ඔබ සලකා බැලිය යුතුය . මතක තබා ගන්න, ගෝලීය විචල්‍යයන් සියල්ලම නරක නැත - දත්ත සමුදායන් අත්‍යවශ්‍යයෙන්ම ගෝලීය විචල්‍යයන්ගේ විශාල කට්ටලයකි. නමුත් ඔබට එය හැසිරවිය හැකි නම් එය තරමක් හොඳයි.

නව ක්‍රමලේඛකයින් සඳහා මෙම ප්‍රශ්නය වෙනත් දෘෂ්ටිකෝණයකින් ආමන්ත්‍රණය කිරීම සඳහා:

අප වස්තු-නැඹුරු වැඩසටහන්කරණය ඉගෙන ගන්නා විට උරුමය බොහෝ විට මුල් අවධියේ උගන්වනු ලැබේ, එබැවින් එය පොදු ගැටලුවකට පහසු විසඳුමක් ලෙස පෙනේ.

මට පන්ති තුනක් ඇත, සියල්ලටම පොදු ක්‍රියාකාරිත්වයක් අවශ්‍ය වේ. එබැවින් මම මූලික පංතියක් ලියා ඔවුන් සියල්ලන්ටම එයින් උරුමකම් ලබා දුන්නොත්, ඔවුන් සියල්ලන්ටම එම ක්‍රියාකාරීත්වය ලැබෙනු ඇති අතර මට අවශ්‍ය වන්නේ එය එකවර පවත්වා ගෙන යාම පමණි.

එය විශිෂ්ටයි, නමුත් ප්‍රායෝගිකව එය කිසි විටෙකත්, කිසි විටෙකත් ක්‍රියා නොකරයි, එක් හේතුවක් නිසා:

• අපගේ පංති වලට අවශ්‍ය තවත් කාර්යයන් කිහිපයක් ඇති බව අපි සොයා ගනිමු. අප පන්තිවලට ක්‍රියාකාරීත්වය එකතු කරන ආකාරය උරුමය හරහා නම්, අප විසින් තීරණය කළ යුතුය - එයින් උරුම වන සෑම පන්තියකටම එම ක්‍රියාකාරීත්වය අවශ්‍ය නොවුවද, අපි එය පවතින මූලික පන්තියට එකතු කරමු ද? අපි වෙනත් මූලික පන්තියක් නිර්මාණය කරනවාද? නමුත් දැනටමත් වෙනත් මූලික පන්තියෙන් උරුම වී ඇති පන්ති ගැන කුමක් කිව හැකිද?
• අපගේ මූලික පන්තියෙන් උරුම වන එක් පන්තියක් සඳහා පමණක් අපට අවශ්‍ය වන්නේ මූලික පන්තිය ටිකක් වෙනස් ලෙස හැසිරීමටයි. දැන් අපි ආපසු ගොස් අපගේ මූලික පන්තිය සමඟ ටින්කර් කරන්නෙමු, සමහර විට අථත්‍ය ක්‍රම කිහිපයක් එකතු කිරීම හෝ ඊටත් වඩා නරක නම්, “මට උරුම A වර්ගය නම්, මෙය කරන්න, නමුත් මට B වර්ගය උරුම වී ඇත්නම්, එසේ කරන්න . " එය හේතු රාශියක් නිසා නරක ය. එකක් නම්, අපි මූලික පන්තිය වෙනස් කරන සෑම අවස්ථාවකම, අපි උරුම කරගත් සෑම පන්තියක්ම effectively ලදායී ලෙස වෙනස් කිරීමයි. ඒ නිසා අපි A, B, C, සහ D පන්තිය වෙනස් කරන්නේ අපට A පන්තියේ තරමක් වෙනස් හැසිරීමක් අවශ්‍ය නිසා ය. අප සිතන තරම් පරිස්සමින්, අපි එම පන්ති වලින් එකක් බිඳ දැමිය හැකිය. පන්ති.
• මෙම පංති සියල්ලම එකිනෙකාගෙන් උරුම කර ගැනීමට අප තීරණය කළේ ඇයිදැයි අපි දනිමු, නමුත් අපගේ කේතය පවත්වා ගෙන යා යුතු වෙනත් කෙනෙකුට එය බොහෝ විට තේරුමක් නොවනු ඇත. අපි ඔවුන්ට අසීරු තේරීමක් කිරීමට බල කළ හැකිය - මට අවශ්‍ය වෙනස සිදු කිරීම සඳහා මම ඇත්තෙන්ම අවලස්සන හා අවුල් සහගත දෙයක් කරනවාද (පෙර වෙඩි උණ්ඩය බලන්න) හෝ මම මේ පොකුරක් නැවත ලියන්නේද?

අවසානයේදී, අපි අපගේ කේතය දුෂ්කර ගැට කිහිපයක ගැට ගසා එයින් කිසිදු ප්‍රතිලාභයක් ලබා නොගනිමු, "සිසිල්, මම උරුමය ගැන ඉගෙන ගත් අතර දැන් මම එය භාවිතා කළෙමි." අප සියල්ලන්ම එය කර ඇති නිසා එය සංවර්‍ධනය වීමට අදහස් නොකෙරේ. නමුත් අපි හැමෝම එය කළේ කිසිවෙකු අපට නොකියන නිසාය.

කවුරුහරි මට "උරුමයට වඩා වාසිදායක සංයුතිය" පැහැදිලි කළ විගස, මම උරුමය භාවිතා කරමින් පන්ති අතර ක්‍රියාකාරීත්වය බෙදා ගැනීමට උත්සාහ කළ සෑම අවස්ථාවකම නැවත සිතා බැලුවෙමි.

ප්‍රතිවෛරසය යනු තනි වගකීම් මූලධර්මයයි . එය බාධකයක් ලෙස සිතන්න. මගේ පන්තිය එක දෙයක් කළ යුතුයි . මම කළ යුතුයි මගේ පන්තියේ කෙසේ හෝ එක දෙයක් ඒ කියන්නෙ විස්තර කරන නම ලබා දීමට. (සෑම දෙයකටම ව්‍යතිරේකයන් ඇත, නමුත් අප ඉගෙන ගන්නා විට නිරපේක්ෂ නීති සමහර විට වඩා හොඳය.) එයින් කියවෙන්නේ මට මූලික පංතියක් ලිවිය නොහැකි ObjectBaseThatContainsVariousFunctionsNeededByDifferentClassesබවයි. ඕනෑම දෙයක් වෙනස් ක්රියාකාරිත්වය මම අවශ්ය තමන්ගේ ම පන්ති විය යුතුය, සහ අවශ්ය ක්රියාකාරිත්වය බව පන්තිය මත රඳා පවතී හැකි බව, වෙනත් නම් පන්ති නෑ එය උරුම.

අතිරික්ත කිරීමේ අවදානමක දී, එය සංයුතියයි - එකට වැඩ කිරීම සඳහා බහු පන්ති රචනා කිරීම. අප එම පුරුද්ද ඇති කරගත් පසු එය උරුමය භාවිතා කිරීමට වඩා නම්‍යශීලී, නඩත්තු කළ හැකි සහ පරීක්ෂා කළ හැකි බව අපට පෙනී යයි.

සලකා බැලීම් / සලකා බැලීම් හැරුණු විට, ඔබේ වස්තුව හරහා යා යුතු උරුමයේ “ගැඹුර” ද සලකා බැලිය යුතුය. උරුමයේ මට්ටම් පහක් හෝ හයක් ඉක්මවා යන ඕනෑම දෙයක් අනපේක්ෂිත වාත්තු කිරීම සහ බොක්සිං / නොබොක්සිං ගැටළු ඇති කළ හැකි අතර, එවැනි අවස්ථාවන්හිදී ඔබේ වස්තුව රචනා කිරීම නුවණට හුරුය.

ඔබ ඇති විට ය, එනම් පන්ති දෙක (උදාහරණයක් බල්ලෙකු බලු මිල) අතර සම්බන්ධයක්, ඔබ උරුම සඳහා යන්න.

අනෙක් අතට ඔබ ඇති විට ඇති, එනම් හෝ පන්ති දෙක අතර යම් නාම සඳහා නාම විශේෂනයක් සම්බන්ධතාවය හෝ (ගුරු අධ්යයන පාඨමාලා) (ශිෂ්ය පාඨමාලා ඇත), ඔබ සංයුතිය තීරණය කළේය.

මෙය අවබෝධ කර ගැනීම සඳහා සරල ක්‍රමයක් වනුයේ ඔබේ පන්තියේ වස්තුවක් එහි මව් පංතියට සමාන අතුරු මුහුණතක් තිබිය යුතු විට උරුමය භාවිතා කළ යුතු අතර එමඟින් එය මව් පන්තියේ වස්තුවක් ලෙස සැලකිය හැකිය (උඩු යටිකුරු කිරීම) . තවද, ව්‍යුත්පන්න පංති වස්තුවක ක්‍රියාකාරී ඇමතුම් කේතයේ සෑම තැනකම එලෙසම පවතිනු ඇත, නමුත් ඇමතීමට නිශ්චිත ක්‍රමය ක්‍රියාත්මක වන වේලාවේදී තීරණය වේ (එනම් පහත් මට්ටමේ ක්‍රියාත්මක කිරීම වෙනස් වේ, ඉහළ මට්ටමේ අතුරු මුහුණත එලෙසම පවතී).

ඔබට නව පන්තියට එකම අතුරු මුහුණතක් අවශ්‍ය නොවන විට සංයුතිය භාවිතා කළ යුතුය, එනම් පංතියේ ක්‍රියාත්මක කිරීමේ සමහර අංග සැඟවීමට ඔබ අදහස් කරන්නේ එම පන්තියේ පරිශීලකයා නොදැන සිටිය යුතුය. සංයුතිය වැඩි සහාය මාර්ගය ගැන, එසේ encapsulation උරුම සහාය අදහස් කර ඇති අතර (එනම්, ක්රියාත්මක කිරීම සඳහා තමාම) වියුක්තීකරණය (එනම් යම් දෙයක් පිළිබඳ සරල නියෝජන, මෙම නඩුවේ ලබා එම විවිධ අභ්යන්තර සමග වර්ග රැසක් සඳහා අතුරු මුහුණත්).

ආක්‍රමණ ගණනය කළ හැකි උප ප්‍රභේදය සුදුසු සහ වඩා බලවත් ය, එසේ නොමැතිනම් විස්තාරණතාව සඳහා ක්‍රියාකාරී සංයුතිය භාවිතා කරන්න.

A පෙවෙල් සමඟ මම එකඟ වෙමි, ඔහු පවසන විට, සංයුතිය සඳහා ස්ථාන සහ උරුමය සඳහා ස්ථාන තිබේ.

ඔබගේ පිළිතුර මෙම ඕනෑම ප්‍රශ්නයකට සහතික කිරීමක් නම් උරුමය භාවිතා කළ යුතු යැයි මම සිතමි.

• ඔබේ පන්තිය බහුමාපකයෙන් ප්‍රයෝජන ගන්නා ව්‍යුහයක කොටසක්ද? නිදසුනක් ලෙස, ඔබට හැඩ පංතියක් තිබේ නම්, එය දිනුම් ඇදීම () ලෙස නම් කර තිබේ නම්, අපට පැහැදිලිවම රවුම සහ චතුරස්ර පන්ති හැඩයේ උප පංති විය යුතුය, එවිට ඔවුන්ගේ සේවාදායක පන්ති රඳා පවතින්නේ හැඩය මත මිස නිශ්චිත උප පංති මත නොවේ.
• ඔබේ පන්තියට වෙනත් පන්තියක අර්ථ දක්වා ඇති ඉහළ මට්ටමේ අන්තර්ක්‍රියා නැවත භාවිතා කිරීමට අවශ්‍යද? මෙම සැකිල්ල, ක්රමය නිර්මාණය රටාව උරුමය තොරව ක්රියාත්මක කිරීමට නොහැකි වනු ඇත. සියලු විස්තීරණ රාමු මෙම රටාව භාවිතා කරන බව මම විශ්වාස කරමි.

කෙසේ වෙතත්, ඔබේ අභිප්‍රාය හුදෙක් කේත නැවත භාවිතා කිරීමේ අභිප්‍රාය නම්, සංයුතිය බොහෝ විට වඩා හොඳ නිර්මාණ තේරීමක් වේ.

උරුමය යනු කේත නැවත භාවිතා කිරීම සඳහා ඉතා ප්‍රබල යාන්ත්‍රණයකි. නමුත් නිසි ලෙස භාවිතා කළ යුතුය. උප පංතිය මව් පංතියේ උප ප්‍රභේදයක් නම් උරුමය නිවැරදිව භාවිතා වන බව මම කියමි. ඉහත සඳහන් කළ පරිදි මෙහි ප්‍රධාන කරුණ වන්නේ ලිස්කොව් ආදේශන මූලධර්මයයි.

උප පංතිය උප ප්‍රභේදයට සමාන නොවේ. ඔබට උප වර්ග නොවන උප පංති නිර්මාණය කළ හැකිය (ඔබ සංයුතිය භාවිතා කළ යුත්තේ මෙයයි). උප වර්ගයක් යනු කුමක්දැයි වටහා ගැනීමට, වර්ගයක් යනු කුමක්ද යන්න පිළිබඳ පැහැදිලි කිරීමක් ලබා දීමට පටන් ගනිමු.

අංක 5 වර්ගයේ පූර්ණ සංඛ්‍යාවක් බව අප පවසන විට, අපි සඳහන් කරන්නේ 5 විය හැකි අගයන් සමූහයකට අයත් වන බවයි (උදාහරණයක් ලෙස, ජාවා ප්‍රාථමික වර්ග සඳහා විය හැකි අගයන් බලන්න). එකතු කිරීම සහ අඩු කිරීම වැනි අගය මත මට කළ හැකි වලංගු ක්‍රම මාලාවක් ඇති බව ද අපි සඳහන් කරමු. අවසාන වශයෙන් අපි ප්‍රකාශ කරන්නේ සෑම විටම සෑහීමකට පත්වන ගුණාංග සමූහයක් ඇති බවයි, උදාහරණයක් ලෙස, මම 3 සහ 5 අගයන් එකතු කළහොත්, එහි ප්‍රති .ලයක් ලෙස මට 8 ක් ලැබෙනු ඇත.

තවත් උදාහරණයක් ලබා දීම සඳහා, වියුක්ත දත්ත වර්ග, නිඛිල කට්ටල සහ පූර්ණ සංඛ්‍යා ලැයිස්තුව ගැන සිතන්න, ඔවුන්ට තබා ගත හැකි අගයන් පූර්ණ සංඛ්‍යා වලට සීමා වේ. ඔවුන් දෙදෙනාම එකතු කිරීම (නව අගය) සහ ප්‍රමාණය () වැනි ක්‍රම කිහිපයකට සහාය දක්වයි. ඔවුන් දෙදෙනාම විවිධ ගුණාංග ඇත (පන්ති වෙනස් කිරීම), කට්ටල අනුපිටපත් වලට ඉඩ නොදෙන අතර ලැයිස්තුව අනුපිටපත් වලට ඉඩ දෙයි (ඇත්ත වශයෙන්ම ඔවුන් දෙදෙනාම තෘප්තිමත් කරන වෙනත් ගුණාංග තිබේ).

උප වර්ගය ද වෙනත් වර්ගයකට සම්බන්ධයක් ඇති මව් වර්ගය (හෝ සුපර් ටයිප්) ලෙස හැඳින්වේ. උප වර්ගය මව් වර්ගයේ ලක්ෂණ (අගයන්, ක්‍රම සහ ගුණාංග) සපුරාලිය යුතුය. සම්බන්ධතාවය යනු සුපිරි වර්ගය අපේක්ෂා කරන ඕනෑම සන්දර්භයකදී, එය ක්‍රියාත්මක කිරීමේ හැසිරීමට බලපෑමක් නොකර උප ප්‍රභේදයක් මගින් ආදේශ කළ හැකි බවයි. මම කියන දේ නිදර්ශනය කිරීම සඳහා යම් කේතයක් බැලීමට යමු. මම පූර්ණ සංඛ්‍යා ලැයිස්තුවක් ලියමි යැයි සිතමු (යම් ආකාරයක ව්‍යාජ භාෂාවෙන්):

class List {
  data = new Array();

  Integer size() {
    return data.length;
  }

  add(Integer anInteger) {
    data[data.length] = anInteger;
  }
}

ඉන්පසුව, මම පූර්ණ සංඛ්‍යා ලැයිස්තුවේ උප පංතියක් ලෙස පූර්ණ සංඛ්‍යා කට්ටලය ලියමි:

class Set, inheriting from: List {
  add(Integer anInteger) {
     if (data.notContains(anInteger)) {
       super.add(anInteger);
     }
  }
}

අපගේ නිඛිල සංඛ්‍යා පන්තිය පූර්ණ සංඛ්‍යා ලැයිස්තුවේ උප පංතියකි, නමුත් එය උප වර්ගයක් නොවේ, මන්ද එය ලැයිස්තු පන්තියේ සියලුම අංග තෘප්තිමත් නොකිරීමයි. ක්රමවල අගයන් සහ අත්සන සෑහීමකට පත්වන නමුත් ගුණාංග එසේ නොවේ. එකතු කිරීමේ (පූර්ණ සංඛ්‍යා) ක්‍රමයේ හැසිරීම පැහැදිලිවම වෙනස් කර ඇත, මව් වර්ගයේ ගුණාංග ආරක්ෂා නොකරයි. ඔබේ පන්තිවල සේවාදායකයාගේ දෘෂ්ටි කෝණයෙන් සිතන්න. පූර්ණ සංඛ්‍යා ලැයිස්තුවක් අපේක්ෂා කරන පූර්ණ සංඛ්‍යා සමූහයක් ඔවුන්ට ලැබෙනු ඇත. ලැයිස්තුවේ එම අගය දැනටමත් පැවතුනද, අගය එකතු කිරීමට සහ එම අගය ලැයිස්තුවට එක් කිරීමට සේවාදායකයාට අවශ්‍ය විය හැකිය. නමුත් වටිනාකම පවතින්නේ නම් ඇයට එම හැසිරීම නොලැබේ. ඇයට විශාල උත්තරයක්!

මෙය උරුමය අනිසි ලෙස භාවිතා කිරීම පිළිබඳ සම්භාව්‍ය නිදසුනකි. මෙම අවස්ථාවේ දී සංයුතිය භාවිතා කරන්න.

(එයින් කොටසක්: උරුමය නිසි ලෙස භාවිතා කරන්න ).

මා අසා ඇති නියමය නම් උරුමය භාවිතා කළ යුත්තේ එහි “ඇති” සම්බන්ධතාවයක් සහ සංයුතියක් එහි “ඇති විට” ඇති විටය. ඒ සමඟම මට හැඟෙන්නේ ඔබ සැමවිටම සංයුතිය වෙත නැඹුරු විය යුතු නිසා එය බොහෝ සංකීර්ණතා ඉවත් කරන බවයි.

සංයුතිය v / s උරුමය පුළුල් විෂයයකි. වඩා හොඳ දේ සඳහා සැබෑ පිළිතුරක් නැත, ඒ සියල්ල පද්ධතියේ සැලසුම මත රඳා පවතී.

සාමාන්‍යයෙන් වස්තුව අතර සම්බන්ධතාවයේ වර්ගය ඒවායින් එකක් තෝරා ගැනීමට වඩා හොඳ තොරතුරු සපයයි.

සම්බන්ධතා වර්ගය "IS-A" සම්බන්ධතාවය නම්, උරුමය වඩා හොඳ ප්‍රවේශයකි. නැතිනම් සම්බන්ධතා වර්ගය "HAS-A" සම්බන්ධතාවය නම් සංයුතිය වඩා හොඳින් ළඟා වේ.

එය මුළුමනින්ම රඳා පවතින්නේ වස්තු සම්බන්ධතාවය මත ය.

සංයුතිය කැමති වුවත්, මම හොඳ නරක ඉස්මතු කිරීමට කැමති උරුමය හා අවාසි සංයුතිය .

උරුමයේ වාසි:

1. එය තාර්කික " IS A" සම්බන්ධතාවයක් ස්ථාපිත කරයි . නම් මෝටර් රථ හා ට්රක් රථ වර්ග දෙකක් ඇත වාහන (පදනම් පන්තිය), ළමා පන්ති A යනු පදනම පන්තියේ.

   එනම්

   කාර් යනු වාහනයකි

   ට්‍රක් රථය වාහනයකි

2. උරුමය සමඟ, ඔබට හැකියාවක් අර්ථ දැක්වීමට / වෙනස් කිරීමට / දිගු කිරීමට හැකිය

   1. මූලික පන්තිය කිසිදු ක්‍රියාත්මක කිරීමක් සපයන්නේ නැති අතර උප පංතියට සම්පූර්ණ ක්‍රමය ඉක්මවා යා යුතුය (සාරාංශය) => ඔබට කොන්ත්‍රාත්තුවක් ක්‍රියාත්මක කළ හැකිය
   2. මූලික පන්තිය පෙරනිමි ක්‍රියාත්මක කිරීම සපයන අතර උප පංතියට හැසිරීම වෙනස් කළ හැකිය => ඔබට කොන්ත්‍රාත්තුව නැවත අර්ථ දැක්විය හැකිය
   3. පළමු ප්‍රකාශය ලෙස super.methodName () ඇමතීමෙන් උප පංතිය මූලික පන්ති ක්‍රියාත්මක කිරීම සඳහා දිගුවක් එක් කරයි => ඔබට කොන්ත්‍රාත්තුවක් දීර් can කළ හැකිය
   4. මූලික පංතිය ඇල්ගොරිතමයේ ව්‍යුහය නිර්වචනය කරන අතර උප පංතිය ඇල්ගොරිතමයේ කොටසක් අභිබවා යනු ඇත => ඔබට මූලික පන්තියේ ඇටසැකිල්ලෙහි වෙනසක් නොමැතිව Template_method ක්‍රියාත්මක කළ හැකිය.

සංයුතියේ අවාසි:

1. උරුමයේ දී, උප පංතියට IS A සම්බන්ධතාවයක් නිසා මූලික පන්ති ක්‍රමය ක්‍රියාත්මක නොකලද මූලික පන්ති ක්‍රමය කෙලින්ම ක්‍රියාත්මක කළ හැකිය . ඔබ සංයුතිය භාවිතා කරන්නේ නම්, අඩංගු පංති API නිරාවරණය කිරීම සඳහා බහාලුම් පන්තියේ ක්‍රම එකතු කළ යුතුය

උදා: නම් මෝටර් රථ අඩංගු වාහන සහ ඔබ මිල ලබා ගැනීමට නම් මෝටර් රථ අර්ථ කර ඇති, වාහන , ඔබගේ කේතය මෙම සමාන වනු ඇත

class Vehicle{
     protected double getPrice(){
          // return price
     }
} 

class Car{
     Vehicle vehicle;
     protected double getPrice(){
          return vehicle.getPrice();
     }
} 

බොහෝ අය පැවසූ පරිදි, මම මුලින්ම චෙක්පතෙන් ආරම්භ කරමි - “යනු” සම්බන්ධතාවයක් තිබේද යන්න. එය පවතින්නේ නම් මම සාමාන්‍යයෙන් පහත සඳහන් දෑ පරීක්ෂා කරමි:

මූලික පන්තිය ක්ෂණිකව කළ හැකිද යන්න. එනම්, මූලික පන්තිය වියුක්ත නොවන විය හැකිද යන්නයි. එය වියුක්ත නොවන නම් මම සාමාන්‍යයෙන් සංයුතියට කැමතියි

උදා 1. ගණකාධිකාරී යනු සේවකයෙකි. නමුත් මම ඇත නැත උරුමයක් සේවක වස්තුව instantiated හැකි නිසා භාවිතා කරන්න.

උදා: 2. පොත් යනු SellingItem. SellingItem ක්ෂණිකව දැක්විය නොහැක - එය වියුක්ත සංකල්පයකි. එබැවින් මම උරුමයන් භාවිතා කරමි. SellingItem යනු වියුක්ත පාදක පන්තියකි (හෝ C # හි අතුරු මුහුණත )

මෙම ප්‍රවේශය ගැන ඔබ සිතන්නේ කුමක්ද?

එසේම, මම උරුමය කිසිසේත් භාවිතා නොකරන්නේ මන්ද යන්න පිළිබඳ @anon පිළිතුරට සහය දෙමි.

උරුමය භාවිතා කිරීමට ප්‍රධාන හේතුව සංයුතියේ ආකාරයක් නොවේ - එය ඔබට බහුමාමක හැසිරීම ලබා ගත හැකිය. ඔබට බහුමාපකය අවශ්‍ය නොවේ නම්, ඔබ බොහෝ විට උරුමය භාවිතා නොකළ යුතුය.

AtMatthieuM. පවසයි /software/12439/code-smell-inheritance-abuse/12448#comment303759_12448

උරුමය පිළිබඳ ගැටළුව නම් එය විකලාංග අරමුණු දෙකක් සඳහා භාවිතා කළ හැකිය:

අතුරුමුහුණත (බහුමාපකය සඳහා)

ක්‍රියාත්මක කිරීම (කේත නැවත භාවිතා කිරීම සඳහා)

යොමු කිරීම

1. වඩා හොඳ කුමන පන්ති නිර්මාණයද?
2. උරුමය එදිරිව

උරුමය සමඟ ඇතිවිය හැකි දියමන්ති ගැටලුව කිසිවෙකු සඳහන් කර නැති බව මට පෙනේ .

බැලූ බැල්මට, B සහ C පංති A සහ ​​දෙකම ඉක්මවා යන ක්‍රමය X සහ හතරවන පන්තියේ D, B සහ C යන දෙකින්ම උරුම වී ඇත්නම් සහ X අභිබවා නොයන්නේ නම්, XD ක්‍රියාත්මක කිරීම භාවිතා කළ යුත්තේ කවරේද?

විකිපීඩියාව මෙම ප්‍රශ්නයේ සාකච්ඡා කෙරෙන මාතෘකාව පිළිබඳ කදිම දළ විශ්ලේෂණයක් ඉදිරිපත් කරයි.