මගේ වැඩසටහන් සැලසුම් කිරීමේදී, මම බොහෝ විට එවැනි සිතුවිලි දාමයකින් ආරම්භ කරමි:

පාපන්දු කණ්ඩායමක් යනු පාපන්දු ක්‍රීඩකයින්ගේ ලැයිස්තුවක් පමණි. එබැවින්, මම එය නියෝජනය කළ යුත්තේ:

var football_team = new List<FootballPlayer>();

මෙම ලැයිස්තුවේ අනුපිළිවෙල නිරූපණය කරන්නේ ක්‍රීඩකයන් ලැයිස්තුවේ ලැයිස්තුගත කර ඇති අනුපිළිවෙලයි.

නමුත් ක්‍රීඩකයන්ගේ ලැයිස්තුවට අමතරව කණ්ඩායම් වලට වෙනත් දේපලද ඇති බව මම පසුව තේරුම් ගතිමි. උදාහරණයක් ලෙස, මෙම කන්නයේ ධාවනය වන මුළු ලකුණු, වත්මන් අයවැය, ඒකාකාර වර්ණ, stringකණ්ඩායමේ නම නියෝජනය කරන ආදිය.

ඉතින් මම හිතන්නේ:

හරි, පාපන්දු කණ්ඩායමක් යනු ක්‍රීඩකයන්ගේ ලැයිස්තුවකට සමානය, නමුත් ඊට අමතරව, එයට නමක් (අ string) සහ ධාවනය වන මුළු ලකුණු (අ int) ඇත. .නෙට් පාපන්දු කණ්ඩායම් ගබඩා කිරීම සඳහා පන්තියක් සපයන්නේ නැත, එබැවින් මම මගේම පන්තියක් සාදමි. වඩාත්ම සමාන හා අදාළ පවත්නා ව්‍යුහය List<FootballPlayer>, එබැවින් මම එයින් උරුම වෙමි:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

නමුත් ඔබට උරුම නොවිය යුතු යැයි මාර්ගෝපදේශයක් පවසන බවList<T> පෙනේ. මෙම මාර්ගෝපදේශය කාරණා දෙකකින් මම තරයේ ව්‍යාකූල වී සිටිමි.

ඇයි නැත්තේ?

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

මා දුටු තවත් හේතුවක් නම් Listඑය මයික්‍රොසොෆ්ට් විසින් සපයනු ලබන අතර මට එය පාලනය කළ නොහැකි බැවින් "පොදු API" එකක් හෙළි කිරීමෙන් පසුව මට එය පසුව වෙනස් කළ නොහැක . නමුත් මම මෙය තේරුම් ගැනීමට වෙහෙසෙනවා. පොදු API යනු කුමක්ද සහ මා සැලකිලිමත් විය යුත්තේ ඇයි? මගේ වර්තමාන ව්‍යාපෘතියෙහි මෙම පොදු ඒපීඅයි නොමැති නම් සහ නොමැති නම්, මට මෙම මාර්ගෝපදේශය ආරක්ෂිතව නොසලකා හැරිය හැකිද? මට උරුම වී ඇත්නම් List සහ මට පොදු API එකක් අවශ්‍ය බව පෙනේ නම්, මට ඇති දුෂ්කරතා මොනවාද?

එය පවා වැදගත් වන්නේ ඇයි? ලැයිස්තුවක් යනු ලැයිස්තුවකි. වෙනස් විය හැකි දේ කුමක්ද? මට වෙනස් කිරීමට අවශ්‍ය විය හැක්කේ කුමක්ද?

අවසාන වශයෙන්, මයික්‍රොසොෆ්ට් මට උරුම කර ගැනීමට Listඅකමැති නම්, ඔවුන් පන්තිය සෑදුවේ නැත්තේ ඇයි sealed?

මා භාවිතා කිරීමට බලාපොරොත්තු වන්නේ කුමක්ද?

පෙනෙන ආකාරයට, අභිරුචි එකතු කිරීම් සඳහා, මයික්‍රොසොෆ්ට් විසින් Collectionපන්තියක් ලබා දී ඇති අතර ඒ වෙනුවට දීර් extended කළ යුතුය List. නමුත් මෙම පංතිය ඉතා හිස් ය, උදාහරණයක් ලෙසAddRange බොහෝ ප්‍රයෝජනවත් දේ නොමැත . jvitor83 හි පිළිතුර එම විශේෂිත ක්‍රමයට කාර්ය සාධන තාර්කිකත්වයක් සපයයි, නමුත් මන්දගාමී AddRangeවීම වඩා හොඳ නොවන්නේ AddRangeකෙසේද?

උරුම කර ගැනීමට Collectionවඩා වැඩ කිරීම උරුම කර ගැනීම වන අතර Listඑයින් කිසිදු ප්‍රයෝජනයක් මට නොපෙනේ. නිසැකවම මයික්‍රොසොෆ්ට් කිසිදු හේතුවක් නොමැතිව අමතර වැඩක් කිරීමට මට නොකියනු ඇත, එබැවින් මා යම් දෙයක් වරදවා වටහාගෙන ඇති බවක් හැඟීමට මට උදව් කළ නොහැක, සහ උරුම කර Collectionගැනීම ඇත්ත වශයෙන්ම මගේ ගැටලුවට නිවැරදි විසඳුම නොවේ.

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

අවසාන වශයෙන්, සමහරු Listයමක් ඔතා තැබීමට යෝජනා කරති :

class FootballTeam 
{ 
    public List<FootballPlayer> Players; 
}

මේ සමඟ ගැටළු දෙකක් තිබේ:

1. එය මගේ කේතය අනවශ්‍ය ලෙස වාචික කරයි. මම දැන් my_team.Players.Countසාධාරණ ලෙස කතා කළ යුතුයි my_team.Count. ස්තුතිවන්ත වන්න, සී # සමඟ මට සුචිගත කිරීම විනිවිද පෙනෙන ලෙස අර්ථ දැක්විය හැකි අතර අභ්‍යන්තරයේ සියලු ක්‍රම ඉදිරියට යොමු කළ හැකිය List... නමුත් එය කේත ගොඩක්! ඒ සියලු වැඩ සඳහා මට ලැබෙන්නේ කුමක්ද?

2. එය සරල තේරුමක් නැති දෙයක්. පාපන්දු කණ්ඩායමකට ක්‍රීඩකයන්ගේ ලැයිස්තුවක් නොමැත. එය වේ ක්රීඩකයන් ලැයිස්තුව. "ජෝන් මැක්ෆූට්බොලර් සොම්ටීම් හි ක්‍රීඩකයන් සමඟ එකතු වී ඇත" යැයි ඔබ නොකියයි. ඔබ කියනවා "ජෝන් සොම්ටීම් සමඟ සම්බන්ධ වී ඇති". ඔබ "නූලක අක්ෂර" වලට ලිපියක් එක් නොකරයි, ඔබ නූලකට ලිපියක් එක් කරයි. ඔබ පුස්තකාලයක පොත් වලට පොතක් එක් නොකරයි, ඔබ පුස්තකාලයකට පොතක් එක් කරයි.

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

මගේ ප්‍රශ්නය (සාරාංශගත)

මොන දත්ත ව්යුහය නියෝජනය නිවැරදි C # මාර්ගය ( "මිනිස් මනසේ" කියන්න බව) වන, "තර්කානුකූලව", යනු හුදෙක් අය listක thingsවන සීනුව හා නලා කිහිපයක් සමඟ?

උරුම කර ගැනීම List<T>සැමවිටම පිළිගත නොහැකිද? එය පිළිගත හැක්කේ කවදාද? ඇයි / ඇයි නැත්තේ? උරුම කර ගත යුතුද නැද්ද යන්න තීරණය කිරීමේදී ක්‍රමලේඛකයෙකු සලකා බැලිය යුත්තේ List<T>කුමක්ද?

මෙහි හොඳ පිළිතුරු කිහිපයක් තිබේ. මම ඔවුන්ට පහත කරුණු එකතු කරමි.

දත්ත ව්‍යුහයක් නිරූපණය කිරීමේ නිවැරදි C # ක්‍රමය කුමක්ද, එය “තර්කානුකූලව” (එනම් “මිනිස් මනසට”) සීනුව සහ විස්ල් කිහිපයක් ඇති දේවල් ලැයිස්තුවක් පමණි.

පාපන්දු වල පැවැත්ම ගැන හුරුපුරුදු පරිගණක නොවන ක්‍රමලේඛකයින් 10 දෙනෙකුගෙන් හිස්ව පුරවන්නැයි ඉල්ලා සිටින්න:

පාපන්දු කණ්ඩායමක් යනු විශේෂිත _____ වර්ගයකි

කළ කිසිවෙකුට මතය "එය සීනුව හා නලා කිහිපයක් සමඟ පාපන්දු ක්රීඩකයින් ලැයිස්තුව", හෝ ඔවුන් සියලු "ක්රීඩා කණ්ඩායමක්" හෝ "සමාජ" හෝ "සංවිධානය" කිව්වේ? පාපන්දු කණ්ඩායමක් යනු විශේෂිත ක්‍රීඩකයන්ගේ ලැයිස්තුවක් යන ඔබේ අදහස ඔබේ මිනිස් මනසෙහි සහ ඔබේ මිනිස් මනස තුළ පමණි.

List<T>යනු යාන්ත්රණයක් . පාපන්දු කණ්ඩායම යනු ව්‍යාපාරික වස්තුවකි - එනම්, වැඩසටහනේ ව්‍යාපාරික වසමේ ඇති යම් සංකල්පයක් නියෝජනය කරන වස්තුවකි . ඒවා මිශ්‍ර නොකරන්න! පාපන්දු කණ්ඩායමක් යනු එක්තරා ආකාරයක කණ්ඩායමකි; එය සතුව ඇති ලේඛනය, ලේඛනය ක්රීඩකයන් ලැයිස්තුවකි . ලැයිස්තුවක් යනු ක්‍රීඩකයන්ගේ විශේෂිත ලැයිස්තුවක් නොවේ . ලැයිස්තුවක් යනු ක්‍රීඩකයන්ගේ ලැයිස්තුවකි. ඊනියා දේපළ බවට පත් Rosterවූ බව List<Player>. ReadOnlyList<Player>පාපන්දු කණ්ඩායමක් ගැන දන්නා සෑම කෙනෙකුම ක්‍රීඩකයින් ලැයිස්තුවෙන් මකා දැමිය යුතු යැයි ඔබ විශ්වාස නොකරන්නේ නම්, ඔබ එහි සිටින විට එය සාදන්න .

උරුම කර ගැනීම List<T>සැමවිටම පිළිගත නොහැකිද?

කාට පිළිගත නොහැකිද? මට? නැත.

එය පිළිගත හැක්කේ කවදාද?

ඔබ යාන්ත්රණයක් ගොඩනැගීම කරන විට දිග් List<T>යාන්ත්රණයක් .

උරුම කර ගත යුතුද නැද්ද යන්න තීරණය කිරීමේදී ක්‍රමලේඛකයෙකු සලකා බැලිය යුත්තේ List<T>කුමක්ද?

මම යාන්ත්‍රණයක් හෝ ව්‍යාපාර වස්තුවක් ගොඩනඟනවාද ?

නමුත් එය කේත ගොඩක්! ඒ සියලු වැඩ සඳහා මට ලැබෙන්නේ කුමක්ද?

List<T>පනස් ගුණයකින් වැඩි අදාළ සාමාජිකයන් සඳහා ඉදිරියට යැවීමේ ක්‍රම ලිවීමට ඔබ ගෙන යනු ඇතැයි යන ප්‍රශ්නය ටයිප් කිරීමට ඔබ වැඩි කාලයක් ගත කළේය. ඔබ පැහැදිලිවම වාචිකත්වයට බිය නොවන අතර, අපි මෙහි කතා කරන්නේ ඉතා සුළු කේත ප්‍රමාණයක් ගැන ය; මෙය මිනිත්තු කිහිපයක වැඩකි.

යාවත්කාලීන කරන්න

මම එයට තවත් කල්පනා කළ අතර පාපන්දු කණ්ඩායමක් ක්‍රීඩකයන්ගේ ලැයිස්තුවක් ලෙස නිරූපනය නොකිරීමට තවත් හේතුවක් තිබේ. ඇත්ත වශයෙන්ම පාපන්දු කණ්ඩායමක් ක්‍රීඩකයන්ගේ ලැයිස්තුවක් ඇති බවට නිරූපණය කිරීම නරක අදහසක් විය හැකිය . ක්‍රීඩකයන් ලැයිස්තුවක් තිබීම / තිබීම කණ්ඩායමක් සමඟ ඇති ගැටළුව නම්, ඔබට ලැබී ඇත්තේ මොහොතකට කණ්ඩායමේ ඡායාරූපයක් වීමයි . මෙම පංතිය සඳහා ඔබේ ව්‍යාපාරික නඩුව කුමක්දැයි මම නොදනිමි, නමුත් මට පාපන්දු කණ්ඩායමක් නියෝජනය කරන පංතියක් තිබේ නම් මට එය ඇසීමට අවශ්‍ය වනුයේ "2003 සහ 2013 අතර ඇති වූ තුවාල හේතුවෙන් සීහවුක්ස් ක්‍රීඩකයින් කීදෙනෙකුට ක්‍රීඩා මඟ හැරී ඇත්ද?" හෝ "මීට පෙර වෙනත් කණ්ඩායමක් සඳහා ක්‍රීඩා කළ ඩෙන්වර් ක්‍රීඩකයාට වසර පුරා විශාලතම අංගන වැඩිවීම කුමක්ද?" හෝ " igs රන් මේ අවුරුද්ද පුරාම ගියාද? "

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

ඇවැත්නි, ඔබගේ ලිපියේ ප්‍රශ්න හා කරුණු රාශියක් ඇත. මයික්‍රොසොෆ්ට් වෙතින් ඔබට ලැබෙන බොහෝ හේතු හරියටම වේ. අපි සෑම දෙයක්ම සමඟ ආරම්භ කරමුList<T>

• List<T> ඇත ඉතා නිපදවූවකි. එහි ප්‍රධාන භාවිතය වස්තුවක පෞද්ගලික සාමාජිකයෙකු ලෙස භාවිතා කිරීමයි.
• මයික්‍රොසොෆ්ට් එය මුද්‍රා නොකළේ සමහර විට ඔබට මිත්‍රශීලී නමක් ඇති පන්තියක් නිර්මාණය කිරීමට අවශ්‍ය විය හැකි බැවිනි : class MyList<T, TX> : List<CustomObject<T, Something<TX>> { ... }. දැන් එය කිරීම තරම් පහසු ය var list = new MyList<int, string>();.
• CA1002: සාමාන්‍ය ලැයිස්තු හෙළි නොකරන්න : මූලික වශයෙන්, ඔබ මෙම යෙදුම එකම සංවර්ධකයා ලෙස භාවිතා කිරීමට අදහස් කළත්, හොඳ කේතීකරණ භාවිතයන් සමඟ සංවර්ධනය කිරීම වටී, එබැවින් ඒවා ඔබ හා දෙවන ස්වභාවය තුළට ඇතුල් වේ. IList<T>සුචිගත ලැයිස්තුවක් තබා ගැනීමට ඔබට ඕනෑම පාරිභෝගිකයෙකුට අවශ්‍ය නම් ලැයිස්තුවක් හෙළි කිරීමට ඔබට තවමත් අවසර ඇත. මෙය පසුව පංතියක් තුළ ක්‍රියාත්මක කිරීම වෙනස් කරමු.
• මයික්‍රොසොෆ්ට් Collection<T>ඉතා සාමාන්‍ය දෙයක් බවට පත් කළේ එය සාමාන්‍ය සංකල්පයක් නිසා ... නම ඒ සියල්ල පවසයි; එය එකතුවක් පමණි. වැනි වඩාත් නිවැරදි ආකාර ඇත SortedCollection<T>, ObservableCollection<T>, ReadOnlyCollection<T>ක්රියාත්මක වන එක් එක්, ආදිය IList<T>නමුත් නොවේ List<T> .
• Collection<T>සාමාජිකයින්ට (එනම් එකතු කිරීම, ඉවත් කිරීම යනාදිය) අථත්‍ය බැවින් ඒවා අභිබවා යාමට ඉඩ දෙයි. List<T>නැහැ.
• ඔබගේ ප්‍රශ්නයේ අවසාන කොටස ක්‍රියාත්මක වේ. පාපන්දු කණ්ඩායමක් යනු ක්‍රීඩකයන්ගේ ලැයිස්තුවකට වඩා වැඩි ය, එබැවින් එය එම ක්‍රීඩකයන්ගේ ලැයිස්තුව අඩංගු පන්තියක් විය යුතුය. සංයුතිය එදිරිව උරුමය ගැන සිතන්න . ඒ පාපන්දු කණ්ඩායම ඇත ක්රීඩකයන් ලැයිස්තුවක් (අ ලේඛනය), එය ක්රීඩකයන් ලැයිස්තුවක් නැත.

මම මෙම කේතය ලියන්නේ නම් පන්තිය එවැනි දෙයක් ලෙස පෙනේ:

public class FootballTeam
{
    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    // Yes. I used LINQ here. This is so I don't have to worry about
    // _roster.Length vs _roster.Count vs anything else.
    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal;
}

පෙර කේතයේ තේරුම: වීථියේ පිරිමි ළමයින් කණ්ඩායමක් පාපන්දු ක්‍රීඩා කරන අතර ඔවුන්ට නමක් ඇත. වැනි දෙයක්:

කෙසේ වෙතත්, මෙම කේතය (මගේ පිළිතුරෙන්)

public class FootballTeam
{
    // A team's name
    public string TeamName; 

    // Football team rosters are generally 53 total players.
    private readonly List<T> _roster = new List<T>(53);

    public IList<T> Roster
    {
        get { return _roster; }
    }

    public int PlayerCount
    {
        get { return _roster.Count(); }
    }

    // Any additional members you want to expose/wrap.
}

ක්‍රම: මෙය පාපන්දු, කළමනාකරණය, ක්‍රීඩකයින්, පරිපාලකයින් යනාදිය ඇත.

ඔබගේ තර්කනය පින්තූරවල ඉදිරිපත් කරන්නේ එලෙසයි…

මෙය සංයුතියට එදිරිව උරුමය පිළිබඳ සම්භාව්‍ය නිදසුනකි .

මෙම විශේෂිත අවස්ථාවෙහිදී:

කණ්ඩායම යනු අමතර හැසිරීම් සහිත ක්‍රීඩකයන්ගේ ලැයිස්තුවකි

හෝ

කණ්ඩායම ක්‍රීඩකයන්ගේ ලැයිස්තුවක් අඩංගු වන තමන්ගේම වස්තුවක් ද?

ලැයිස්තුව දීර් ing කිරීමෙන් ඔබ ක්‍රම කිහිපයකින් ඔබව සීමා කරයි:

1. ඔබට ප්‍රවේශය සීමා කළ නොහැක (නිදසුනක් ලෙස, ලැයිස්තුව වෙනස් කිරීම නතර කිරීම). ඔබට ඒවා සියල්ලම අවශ්‍යද නැද්ද යන්න ලැයිස්තු ලැයිස්තු ක්‍රම සියල්ලම ඔබට ලැබේ.

2. ඔබට වෙනත් දේවල ලැයිස්තුවක් අවශ්‍ය නම් කුමක් සිදුවේද? නිදසුනක් වශයෙන්, කණ්ඩායම් වලට පුහුණුකරුවන්, කළමනාකරුවන්, පංකා, උපකරණ යනාදිය ඇත. ඒවායින් සමහරක් ඔවුන්ගේම ලැයිස්තුවක් විය හැකිය.

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

සංයුතිය - ඔබේ වස්තුව තුළ ඔබට අවශ්‍ය හැසිරීම ලබා දෙන වස්තුවක් ඇතුළුව.

උරුමය - ඔබේ වස්තුව ඔබට අවශ්‍ය හැසිරීම ඇති වස්තුවක උදාහරණයක් බවට පත්වේ.

දෙකම ඒවායේ භාවිතයන් ඇත, නමුත් මෙය සංයුතිය වඩාත් යෝග්‍ය වන පැහැදිලි අවස්ථාවකි.

සෑම කෙනෙකුම පෙන්වා දී ඇති පරිදි, ක්රීඩකයන් කණ්ඩායමක් ක්රීඩකයන්ගේ ලැයිස්තුවක් නොවේ. මෙම වැරැද්ද සෑම තැනකම බොහෝ අය විසින් සිදු කරනු ලැබේ, සමහර විට විවිධ මට්ටමේ විශේෂ ise තාවයන් ඇත. බොහෝ විට ගැටළුව සියුම් වන අතර ඉඳහිට ඉතා දළ වේ. මේවා ලිස්කොව් ආදේශන මූලධර්මය උල්ලං because නය කරන නිසා එවැනි මෝස්තර නරක ය . මෙම සංකල්පය පැහැදිලි කරන හොඳ ලිපි රාශියක් අන්තර්ජාලයේ ඇත, උදා: http://en.wikipedia.org/wiki/Liskov_substitution_principle

සාරාංශයක් ලෙස, පන්ති අතර දෙමාපිය / ළමා සම්බන්ධතාවයේ ආරක්ෂා කළ යුතු නීති දෙකක් තිබේ:

• දෙමව්පියන් මුළුමනින්ම නිර්වචනය කරන දෙයට වඩා අඩු ලක්ෂණයක් දරුවෙකුට අවශ්‍ය නොවිය යුතුය.
• දරුවා මුළුමනින්ම නිර්වචනය කරන දෙයට අමතරව දෙමව්පියන්ට කිසිදු ලක්ෂණයක් අවශ්‍ය නොවිය යුතුය.

වෙනත් වචන වලින් කිවහොත්, දෙමව්පියන් යනු දරුවෙකු සඳහා අත්‍යවශ්‍ය අර්ථ දැක්වීමක් වන අතර, දරුවෙකු යනු දෙමව්පියන් පිළිබඳ ප්‍රමාණවත් අර්ථ දැක්වීමකි.

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

• පාපන්දු කණ්ඩායමක් පාපන්දු ක්‍රීඩකයින්ගේ ලැයිස්තුවක්ද? (ලැයිස්තුවක ඇති සියලුම ගුණාංග එකම අර්ථයකින් කණ්ඩායමකට අදාළ වේද)
  • කණ්ඩායමක් සමජාතීය ආයතන එකතුවක්ද? ඔව්, කණ්ඩායම යනු ක්‍රීඩකයන්ගේ එකතුවකි
  • ක්‍රීඩකයින් ඇතුළත් කිරීමේ අනුපිළිවෙල කණ්ඩායමේ තත්වය විස්තර කර ඇති අතර පැහැදිලිව වෙනස් නොකළහොත් අනුක්‍රමය ආරක්ෂා වන බව කණ්ඩායම සහතික කරයිද? නැත, නැත
  • කණ්ඩායමේ අනුක්‍රමික තත්ත්වය මත පදනම්ව ක්‍රීඩකයින් ඇතුළත් කිරීමට / අතහැර දැමීමට අපේක්ෂා කරනවාද? නැත

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

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

FootballTeamප්‍රධාන කණ්ඩායම සමඟ සංචිත කණ්ඩායමක් සිටී නම් කුමක් කළ යුතුද?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
}

ඔබ එය නිරූපණය කරන්නේ කෙසේද?

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

සම්බන්ධය පැහැදිලිව ඇත කිසියම් නොව යනු .

නැත්නම් RetiredPlayers?

class FootballTeam
{
    List<FootballPlayer> Players { get; set; }
    List<FootballPlayer> ReservePlayers { get; set; }
    List<FootballPlayer> RetiredPlayers { get; set; }
}

රීතියක් ලෙස, ඔබට කවදා හෝ එකතුවකින් උරුම වීමට අවශ්‍ය නම්, පන්තිය නම් කරන්න SomethingCollection.

ඔබේ SomethingCollectionඅර්ථාන්විත අර්ථයක් තිබේද? ඔබගේ වර්ගය නම් පමණක් මෙය සිදු වන්නේ එකතුව Something.

පිළිබඳ පැමිණිල්ලේ දී FootballTeamඑය නිවැරදි ශබ්ද කරන්නේ නැත. A Teamට වඩා වැඩි ය Collection. Teamඅනෙක් පිළිතුරු පෙන්වා දී ඇති පරිදි A ට පුහුණුකරුවන්, පුහුණුකරුවන් යනාදිය තිබිය හැකිය.

FootballCollectionහරියට පාපන්දු එකතුවක් හෝ සමහර විට පාපන්දු උපකරණ එකතුවක් වගේ. TeamCollection, කණ්ඩායම් එකතුවකි.

FootballPlayerCollectionList<FootballPlayer>ඔබට එය කිරීමට අවශ්‍ය නම් උරුම වන පන්තියකට වලංගු නමක් වන ක්‍රීඩකයන්ගේ එකතුවක් මෙන් පෙනේ.

සැබවින්ම List<FootballPlayer>ගනුදෙනු කිරීමට හොඳ වර්ගයකි. සමහර IList<FootballPlayer>විට ඔබ එය ක්‍රමයකින් ආපසු ලබා දෙන්නේ නම්.

සාරාංශයකින්

ඔබෙන්ම මෙසේ අසන්න

1. ය X එය Y? හෝ තිබේ ද X එය Y?

2. මගේ පන්තියේ නම් වලින් අදහස් කරන්නේ ඒවා මොනවාද?

සැලසුම> ක්‍රියාත්මක කිරීම

ඔබ නිරාවරණය කරන ක්‍රම සහ ගුණාංග නිර්මාණ තීරණයක්. ඔබට උරුම වන්නේ කුමන මූලික පන්තියද යන්න ක්‍රියාත්මක කිරීමේ විස්තරයකි. මට හිතෙනවා කලින් පියවරට පස්සට යන්න වටිනවා කියලා.

වස්තුවක් යනු දත්ත හා හැසිරීම් එකතුවකි.

එබැවින් ඔබේ පළමු ප්‍රශ්න විය යුත්තේ:

• මෙම වස්තුව මා නිර්මාණය කරන ආකෘතියට අයත් දත්ත මොනවාද?
• මෙම වස්තුව එම ආකෘතියේ පෙන්නුම් කරන හැසිරීම කුමක්ද?
• අනාගතයේදී මෙය වෙනස් වන්නේ කෙසේද?

උරුමය යනු "ඊසා" (අ) සම්බන්ධතාවයක් බව මතක තබා ගන්න, සංයුතියෙන් ගම්‍ය වන්නේ "ඇති" (හසා) සම්බන්ධතාවයකි. ඔබගේ යෙදුම පරිණාමය වන විට දේවල් සිදුවිය හැකි ස්ථාන මතක තබා ගනිමින් ඔබේ දැක්ම අනුව ඔබේ තත්වය සඳහා සුදුසු එකක් තෝරන්න.

කොන්ක්‍රීට් වර්ග වලින් සිතීමට පෙර අතුරුමුහුණත් තුළ සිතීම සලකා බලන්න, සමහර අයට ඔවුන්ගේ මොළය ඒ ආකාරයෙන් “සැලසුම් ප්‍රකාරයට” දැමීම පහසුය.

මෙය එදිනෙදා කේතීකරණයේදී සෑම කෙනෙකුම දැනුවත්ව කරන දෙයක් නොවේ. නමුත් ඔබ මේ ආකාරයේ මාතෘකාවක් තෝරාගන්නේ නම්, ඔබ සැලසුම් ජලයේ ගමන් කරයි. ඒ පිළිබඳව දැනුවත් වීම විමුක්තිය විය හැකිය.

සැලසුම් පිරිවිතර සලකා බලන්න

MSDN හෝ Visual Studio හි ලැයිස්තුව <T> සහ IList <T> දෙස බලන්න. ඔවුන් නිරාවරණය කරන ක්‍රම සහ ගුණාංග මොනවාදැයි බලන්න. මෙම ක්‍රම සියල්ලම ඔබේ දෘෂ්ටියට අනුව පාපන්දු කණ්ඩායමකට යමෙකු කිරීමට කැමති දෙයක් මෙන් පෙනේද?

FootballTeam.Reverse () ඔබට තේරුමක් තිබේද? FootballTeam.ConvertAll <TOutput> () ඔබට අවශ්‍ය දෙයක් මෙන් පෙනේද?

මෙය උපක්‍රමශීලී ප්‍රශ්නයක් නොවේ; පිළිතුර අව්‍යාජව “ඔව්” විය හැකිය. ඔබ <Player> හෝ IList <Player> ලැයිස්තුව ක්‍රියාත්මක කරන්නේ නම්, ඔබ ඔවුන් සමඟ සිරවී සිටී; එය ඔබේ ආකෘතියට වඩාත් සුදුසු නම්, එය කරන්න.

ඔබ ඔව් යැයි තීරණය කළහොත් එය අර්ථවත් වන අතර ඔබේ වස්තුව ක්‍රීඩකයන්ගේ එකතුවක් / හැසිරීමක් ලෙස සැලකිය යුතුය (හැසිරීම), එබැවින් ඔබට ICollection හෝ IList ක්‍රියාත්මක කිරීමට අවශ්‍ය නම්, එසේ කරන්න. සංකල්පමය වශයෙන්:

class FootballTeam : ... ICollection<Player>
{
    ...
}

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

class FootballTeam ...
{
    public ICollection<Player> Players { get { ... } }
}

ඔබට අවශ්‍ය වන්නේ ක්‍රීඩකයන් ගණනය කිරීම, එකතු කිරීම හෝ ඉවත් කිරීම වෙනුවට ක්‍රීඩකයන් සමූහය පමණක් ගණනය කිරීමට මිනිසුන්ට හැකි වීමයි. IEnumerable <Player> යනු සලකා බැලිය යුතු පරිපූර්ණ වලංගු විකල්පයකි.

මෙම අතුරු මුහුණත් කිසිවක් ඔබගේ ආකෘතියට කිසිසේත් ප්‍රයෝජනවත් නොවන බව ඔබට හැඟෙනු ඇත. මෙය අඩු ඉඩක් ඇත (IEnumerable <T> බොහෝ අවස්ථාවන්හිදී ප්‍රයෝජනවත් වේ) නමුත් එය තවමත් හැකි ය.

මේවායින් එකක් සෑම අවස්ථාවකම නිශ්චිතව හා නිශ්චිතවම වැරදියි කියා ඔබට පැවසීමට උත්සාහ කරන ඕනෑම අයෙකු නොමඟ යවයි. සෑම අවස්ථාවකදීම එය නිශ්චිතව හා නිශ්චිතවම නිවැරදි යැයි ඔබට පැවසීමට උත්සාහ කරන ඕනෑම අයෙකු නොමඟ යවනු ලැබේ.

ක්‍රියාත්මක කිරීමට ඉදිරියට යන්න

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

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

චින්තන අත්හදා බැලීමකි

කෘතිම උදාහරණයක්: අනෙක් අය සඳහන් කළ පරිදි, කණ්ඩායමක් සෑම විටම ක්‍රීඩකයන්ගේ එකතුවක් පමණක් නොවේ. ඔබ කණ්ඩායම සඳහා තරග ලකුණු එකතුවක් පවත්වාගෙන යනවාද? ඔබේ ආකෘතිය අනුව කණ්ඩායම සමාජය සමඟ හුවමාරු කර ගත හැකිද? එසේ නම්, සහ ඔබේ කණ්ඩායම ක්‍රීඩකයන්ගේ එකතුවක් නම්, සමහර විට එය කාර්ය මණ්ඩලයේ එකතුවක් සහ / හෝ ලකුණු එකතුවකි. එවිට ඔබ අවසන් වන්නේ:

class FootballTeam : ... ICollection<Player>, 
                         ICollection<StaffMember>,
                         ICollection<Score>
{
    ....
}

සැලසුම නොතකා, C # හි මෙම අවස්ථාවෙහිදී ඔබට ලැයිස්තුව <T> වෙතින් උරුම වීමෙන් මේ සියල්ල ක්‍රියාත්මක කිරීමට නොහැකි වනු ඇත, මන්ද C # "පමණක්" තනි උරුමයට සහය දක්වයි. (ඔබ C ++ හි මෙම අක්‍රමිකතාව අත්හදා බැලුවේ නම්, මෙය හොඳ දෙයක් ලෙස ඔබ සලකනු ඇත.) එක් එකතුවක් උරුමය හරහා සහ එක් සංයුතියක් සංයුතිය හරහා ක්‍රියාත්මක කිරීම අපිරිසිදු බවක් දැනේ . ඔබ ILIst <Player> .Count සහ IList <StaffMember> .Count ආදිය පැහැදිලිවම ක්‍රියාත්මක නොකරන්නේ නම් ගණන් කිරීම වැනි ගුණාංග පරිශීලකයින්ට ව්‍යාකූල වේ. එවිට ඒවා ව්‍යාකූල නොවී වේදනාකාරී වේ. මෙය යන්නේ කොතැනට දැයි ඔබට පෙනේ; බඩවැල් හැඟීම මෙම මාවත ගැන සිතන විට ඔබට මෙම දිශාවට ගමන් කිරීම වැරදියි කියා ඔබට කියන්නට පුළුවන (නිවැරදිව හෝ වැරදි ලෙස, ඔබ එය මේ ආකාරයෙන් ක්‍රියාත්මක කළහොත් ඔබේ සගයන් ද විය හැකිය!)

කෙටි පිළිතුර (ප්‍රමාද වැඩියි)

එකතු කිරීමේ පන්ති වලින් උරුම නොවීම පිළිබඳ මාර්ගෝපදේශය C # විශේෂිත නොවේ, ඔබ එය බොහෝ ක්‍රමලේඛන භාෂාවලින් සොයා ගනු ඇත. එයට ප්‍ර wisdom ාව ලැබෙන්නේ නීතියක් නොවේ. ප්‍රායෝගිකව සංයුතිය බොහෝ විට අවබෝධය, ක්‍රියාත්මක කිරීමේ හැකියාව සහ නඩත්තු කිරීමේ හැකියාව අනුව උරුමය දිනා ගැනීම සඳහා සැලකේ. ඔබ වියුක්තයේ ගැඹුරු නොවන්නේ නම්, විශේෂයෙන් කාලය ගත වන විට සහ කේතයේ ඇති වස්තූන්ගේ නිරවද්‍ය දත්ත සහ හැසිරීම හැර, ප්‍රයෝජනවත් හා ස්ථාවර “අයිසා” සබඳතාවලට වඩා ප්‍රයෝජනවත් හා ස්ථාවර “හසා” සබඳතා සොයා ගැනීම සැබෑ ලෝක / වසම් වස්තු සමඟ වඩාත් පොදු වේ. වෙනස්කම්. එකතු කිරීමේ පන්ති වලින් උරුම වීම සැමවිටම බැහැර කිරීමට මෙය හේතු නොවිය යුතුය; නමුත් එය යෝජනා කළ හැකිය.

පළමුවෙන්ම, එය භාවිතයට සම්බන්ධ වේ. ඔබ උරුමය භාවිතා කරන්නේ නම්, Teamපංතිය හුදෙක් වස්තු හැසිරවීම සඳහා නිර්මාණය කර ඇති හැසිරීම් (ක්‍රම) හෙළි කරයි. උදාහරණයක් ලෙස, AsReadOnly()හෝ CopyTo(obj)ක්‍රම මඟින් කණ්ඩායම් වස්තුව සඳහා කිසිදු තේරුමක් නැත. AddRange(items)ක්‍රමවේදය වෙනුවට ඔබට වඩාත් විස්තරාත්මක AddPlayers(players)ක්‍රමයක් අවශ්‍ය වනු ඇත .

ඔබට LINQ භාවිතා කිරීමට අවශ්‍ය නම්, සාමාන්‍ය අතුරු මුහුණතක් ක්‍රියාත්මක කිරීම ICollection<T>හෝ IEnumerable<T>වඩාත් අර්ථවත් වනු ඇත.

සඳහන් කළ පරිදි, සංයුතිය යනු ඒ සඳහා සුදුසුම ක්‍රමයයි. පුද්ගලික විචල්‍යයක් ලෙස ක්‍රීඩකයන්ගේ ලැයිස්තුවක් ක්‍රියාත්මක කරන්න.

පාපන්දු කණ්ඩායමක් යනු පාපන්දු ක්‍රීඩකයින්ගේ ලැයිස්තුවක් නොවේ . පාපන්දු කණ්ඩායමක් පාපන්දු ක්‍රීඩකයින්ගේ ලැයිස්තුවකින් සමන්විත වේ !

මෙය තර්කානුකූලව වැරදියි:

class FootballTeam : List<FootballPlayer> 
{ 
    public string TeamName; 
    public int RunningTotal 
}

මෙය නිවැරදි ය:

class FootballTeam 
{ 
    public List<FootballPlayer> players
    public string TeamName; 
    public int RunningTotal 
}

එය සන්දර්භය මත රඳා පවතී

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

අපැහැදිලි අර්ථ නිරූපණය

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

පන්ති විස්තීරණ වේ

ඔබ එක් සාමාජිකයෙකු පමණක් සිටින පන්තියක් භාවිතා කරන විට (උදා IList activePlayers), සන්දර්භය පැහැදිලි කිරීම සඳහා ඔබට සාමාජිකයාගේ නම (සහ ඊට අමතරව එහි අදහස්) භාවිතා කළ හැකිය. අතිරේක සන්දර්භයන් ඇති විට, ඔබ අතිරේක සාමාජිකයෙකු එක් කරන්න.

පන්ති වඩාත් සංකීර්ණයි

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

නිගමනය / සලකා බැලීම

ඔබට නිශ්චිත සන්දර්භයක් ඇති විට, කණ්ඩායමක් ක්‍රීඩකයන්ගේ ලැයිස්තුවක් ලෙස සැලකීම හරි. උදාහරණයක් ලෙස ක්‍රමයක් තුළ ලිවීම සම්පූර්ණයෙන්ම හරි:

IList<Player> footballTeam = ...

F # භාවිතා කරන විට, වර්ගයේ කෙටි යෙදුමක් සෑදීම පවා හරි විය හැකිය:

type FootballTeam = IList<Player>

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

ඔබේ ප්‍රශ්නය නැවත ලිවීමට මට ඉඩ දෙන්න. එබැවින් ඔබට විෂය වෙනත් දෘෂ්ටිකෝණයකින් දැකිය හැකිය.

මට පාපන්දු කණ්ඩායමක් නියෝජනය කිරීමට අවශ්‍ය වූ විට, එය මූලික වශයෙන් නමක් බව මට වැටහේ. වැනි: "ඊගල්ස්"

string team = new string();

පසුව මට වැටහුණා කණ්ඩායම්වලට ක්‍රීඩකයන් සිටින බව.

මට ක්‍රීඩකයන්ගේ ලැයිස්තුවක් තබා ගැනීම සඳහා මට නූල් වර්ගය දිගු කළ නොහැක්කේ ඇයි?

ඔබේ ගැටලුවට ඇතුල් වීමේ ස්ථානය අත්තනෝමතික ය. කණ්ඩායමක් කුමක්ද සිතීමට උත්සාහ කර එය කුමක්ද (ගුණ), නො වේ .

ඔබ එය කළ පසු, එය වෙනත් පංති සමඟ දේපල බෙදා ගන්නේ දැයි ඔබට දැකගත හැකිය. උරුමය ගැන සිතන්න.

මා සිතන ආකාරයට අනෙක් පිළිතුරු පාපන්දු කණ්ඩායමක් "යනු" List<FootballPlayer>හෝ "තිබේ" යන්න පිළිබඳ ස්පර්ශකයකින් බැහැර වන අතර එය List<FootballPlayer>ලියා ඇති පරිදි මෙම ප්‍රශ්නයට සැබවින්ම පිළිතුරු සපයන්නේ නැත.

උරුම කර ගැනීම සඳහා වන මාර්ගෝපදේශ පිළිබඳ පැහැදිලි කිරීමක් OP ප්‍රධාන වශයෙන් ඉල්ලා සිටී List<T>:

මාර්ගෝපදේශයක් පවසන්නේ ඔබට උරුම නොවිය යුතු බවයි List<T>. ඇයි නැත්තේ?

List<T>අථත්ය ක්රම නොමැති නිසා . මෙය සාමාන්‍යයෙන් ඔබේම කේතයේ ඇති ගැටළුවට වඩා අඩුය, මන්ද ඔබට සාමාන්‍යයෙන් ක්‍රියාත්මක කිරීම සාපේක්ෂව සුළු වේදනාවක් සහිතව මාරු කළ හැකි නමුත් පොදු API එකක වඩා විශාල ගනුදෙනුවක් විය හැකිය.

පොදු API යනු කුමක්ද සහ මා සැලකිලිමත් විය යුත්තේ ඇයි?

පොදු API යනු ඔබ තෙවන පාර්ශවීය ක්‍රමලේඛකයන්ට නිරාවරණය කරන අතුරු මුහුණතකි. රාමු කේතය සිතන්න. යොමු කර ඇති මාර්ගෝපදේශ “.නෙට් රාමු සැලසුම් මාර්ගෝපදේශ” මිස “.නෙට් යෙදුම් සැලසුම් මාර්ගෝපදේශ” නොවන බව මතක තබා ගන්න. වෙනසක් ඇත, සහ - පොදුවේ ගත් කල - පොදු API නිර්මාණය වඩාත් දැඩි ය.

මගේ වර්තමාන ව්‍යාපෘතියෙහි මෙම පොදු ඒපීඅයි නොමැති නම් සහ නොමැති නම්, මට මෙම මාර්ගෝපදේශය ආරක්ෂිතව නොසලකා හැරිය හැකිද? මට ලැයිස්තුවෙන් උරුම වූ අතර මට පොදු API එකක් අවශ්‍ය බව පෙනේ නම්, මට ඇති දුෂ්කරතා මොනවාද?

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

ඔබ අනාගතයේ දී පොදු ඒපීඅයි එකක් එකතු කරන්නේ නම්, එක්කෝ ඔබ ක්‍රියාත්මක කිරීමෙන් ඔබේ ඒපීඅයි සාරාංශ ගත කළ යුතුය (ඔබ List<T>කෙලින්ම නිරාවරණය නොකිරීමෙන් ) හෝ අනාගතයේදී ඇති විය හැකි වේදනාව සමඟ මාර්ගෝපදේශ උල්ලං late නය කිරීම.

එය පවා වැදගත් වන්නේ ඇයි? ලැයිස්තුවක් යනු ලැයිස්තුවකි. වෙනස් විය හැකි දේ කුමක්ද? මට වෙනස් කිරීමට අවශ්‍ය විය හැක්කේ කුමක්ද?

සන්දර්භය මත රඳා පවතී, නමුත් අපි FootballTeamඋදාහරණයක් ලෙස භාවිතා කරන බැවින් - FootballPlayerකණ්ඩායමට වැටුප් සීමාව ඉක්මවා යාමට එය හේතු වේ නම් ඔබට එය එකතු කළ නොහැකි යැයි සිතන්න . එකතු කළ හැකි ක්‍රමයක් පහත පරිදි වේ:

 class FootballTeam : List<FootballPlayer> {
     override void Add(FootballPlayer player) {
        if (this.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
 }

අහ් ... නමුත් ඔබට එය කළ නොහැකි override Addනිසා virtual(කාර්ය සාධන හේතු නිසා).

ඔබ යෙදුමක සිටී නම් (මූලික වශයෙන්, ඔබ සහ ඔබගේ සියලු අමතන්නන් එකට සම්පාදනය කර ඇති බව අදහස් වේ) එවිට ඔබට දැන් IList<T>ඕනෑම සම්පාදක දෝෂයක් භාවිතා කර වෙනස් කළ හැකිය :

 class FootballTeam : IList<FootballPlayer> {
     private List<FootballPlayer> Players { get; set; }

     override void Add(FootballPlayer player) {
        if (this.Players.Sum(p => p.Salary) + player.Salary > SALARY_CAP)) {
          throw new InvalidOperationException("Would exceed salary cap!");
        }
     }
     /* boiler plate for rest of IList */
 }

නමුත්, ඔබ තෙවන පාර්ශවයකට ප්‍රසිද්ධියේ නිරාවරණය වී ඇත්නම්, ඔබ විසින් සම්පාදනය සහ / හෝ ධාවන කාල දෝෂ ඇති කරන බිඳෙන සුළු වෙනසක් සිදු කර ඇත.

TL; DR - මාර්ගෝපදේශ පොදු API සඳහා වේ. පුද්ගලික API සඳහා, ඔබට අවශ්‍ය දේ කරන්න.

මිනිසුන්ට කීමට ඉඩ දෙයි

myTeam.subList(3, 5);

කිසියම් තේරුමක් තිබේද? එසේ නොවේ නම් එය ලැයිස්තුවක් නොවිය යුතුය.

එය ඔබගේ "කණ්ඩායම්" වස්තුවේ හැසිරීම මත රඳා පවතී . එය එකතුවක් මෙන් හැසිරෙන්නේ නම්, එය මුලින් සරල ලැයිස්තුවක් සමඟ නිරූපණය කිරීම හරි විය හැකිය. එවිට ඔබ ලැයිස්තුවේ පුනරාවර්තනය වන කේත අනුපිටපත් කරන බව ඔබට පෙනෙනු ඇත; මෙම අවස්ථාවෙහිදී ඔබට ක්‍රීඩකයන්ගේ ලැයිස්තුව ඔතා ඇති පාපන්දු ක්‍රීඩා වස්තුවක් නිර්මාණය කිරීමේ අවස්ථාව ඇත. පාපන්දු කණ්ඩායමේ පන්තිය ක්‍රීඩකයන්ගේ ලැයිස්තුවේ නැවත සඳහන් වන සියලුම කේත සඳහා නිවහන බවට පත්වේ.

එය මගේ කේතය අනවශ්‍ය ලෙස වාචික කරයි. මම දැන් my_team.Clay වෙනුවට my_team.Players.Count අමතන්න. ස්තුතිවන්ත වන්න, සී # සමඟ මට සුචිගත කිරීම විනිවිද පෙනෙන ලෙස අර්ථ දැක්විය හැකි අතර අභ්‍යන්තර ලැයිස්තුවේ සියලුම ක්‍රම ඉදිරියට යොමු කළ හැකිය ... නමුත් එය කේත ගොඩක්! ඒ සියලු වැඩ සඳහා මට ලැබෙන්නේ කුමක්ද?

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

එය සරල තේරුමක් නැති දෙයක්. පාපන්දු කණ්ඩායමකට ක්‍රීඩකයන්ගේ ලැයිස්තුවක් නොමැත. එය ක්‍රීඩකයන්ගේ ලැයිස්තුවයි. "ජෝන් මැක්ෆූට්බොලර් සොම්ටීම් හි ක්‍රීඩකයන් සමඟ එකතු වී ඇත" යැයි ඔබ නොකියයි. ඔබ කියනවා "ජෝන් සොම්ටීම් සමඟ සම්බන්ධ වී ඇති". ඔබ "නූලක අක්ෂර" වලට ලිපියක් එක් නොකරයි, ඔබ නූලකට ලිපියක් එක් කරයි. ඔබ පුස්තකාලයක පොත් වලට පොතක් එක් නොකරයි, ඔබ පුස්තකාලයකට පොතක් එක් කරයි.

හරියටම :) ඔබ කියනු ඇත්තේ පාපන්දු ටීම්.අඩ් (ජෝන්) මිස පාපන්දු ටීම් නොවේ. ලැයිස්තුව. එකතු කරන්න (ජෝන්). අභ්‍යන්තර ලැයිස්තුව නොපෙනේ.

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

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

ඔබට උරුම වූ විට List, අනෙක් සියලුම වස්තූන් ඔබව ලැයිස්තුවක් ලෙස දැකිය හැකිය. ක්රීඩකයන් එකතු කිරීම සහ ඉවත් කිරීම සඳහා ක්රම වලට ඔවුන්ට access ජු ප්රවේශයක් ඇත. ඔබේ පාලනය ඔබට අහිමි වනු ඇත; උදාහරණයක් වශයෙන්:

ක්‍රීඩකයෙකු විශ්‍රාම ගියද, ඉල්ලා අස්වූවාද, සේවයෙන් පහ කළේද යන්න දැන ගැනීමෙන් ඔබ වෙන්කර හඳුනා ගැනීමට අවශ්‍ය යැයි සිතමු. RemovePlayerසුදුසු ආදාන සංඛ්‍යාවක් ලබා ගන්නා ක්‍රමයක් ඔබට ක්‍රියාත්මක කළ හැකිය . කෙසේ වෙතත්, සිට උරුම විසින් List, ඔබ සෘජුවම ප්රවේශ වැළැක්වීම සඳහා ගෙවාගත නොහැකි වනු ඇත Remove, RemoveAllපවා හා Clear. එහි ප්‍රති As ලයක් වශයෙන්, ඔබ ඇත්ත වශයෙන්ම ඔබේ FootballTeamපන්තිය අක්‍රීය කර ඇත.

සංසරණය පිළිබඳ අමතර අදහස් ... ඔබ පහත සඳහන් කරුණු මතු කළා:

එය මගේ කේතය අනවශ්‍ය ලෙස වාචික කරයි. මම දැන් my_team.Clay වෙනුවට my_team.Players.Count අමතන්න.

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

ඔබ තවදුරටත් මෙසේ කියයි:

එය සරල තේරුමක් නැති දෙයක්. පාපන්දු කණ්ඩායමකට ක්‍රීඩකයන්ගේ ලැයිස්තුවක් නොමැත. එය ක්‍රීඩකයන්ගේ ලැයිස්තුවයි. "ජෝන් මැක්ෆූට්බොලර් සොම්ටීම් හි ක්‍රීඩකයන් සමඟ එකතු වී ඇත" යැයි ඔබ නොකියයි. ඔබ කියනවා "ජෝන් සොම්ටීම් සමඟ සම්බන්ධ වී ඇති".

පළමු බිට් එක ගැන ඔබ වැරදියි: 'ලැයිස්තුව' යන වචනය අතහරින්න, ඇත්ත වශයෙන්ම කණ්ඩායමකට ක්‍රීඩකයන් සිටින බව පැහැදිලිය.
කෙසේ වෙතත්, ඔබ දෙවැන්න සමඟ නියපොතු හිසට පහර දුන්නා. ඔබට සේවාදායකයින් ඇමතීමට අවශ්‍ය නැත ateam.Players.Add(...). ඔබට ඔවුන් ඇමතීමට අවශ්‍යයි ateam.AddPlayer(...). ඔබේ ක්‍රියාත්මක කිරීම (සමහර විට වෙනත් දේ අතර) Players.Add(...)අභ්‍යන්තරව කැඳවනු ඇත.

ඔබේ වස්තූන් සවිබල ගැන්වීමේ පරමාර්ථය සඳහා සංසරණය කෙතරම් වැදගත් දැයි ඔබට දැක ගත හැකිය. වෙනත් වස්තූන්ගෙන් ඇඟිලි ගැසීමට බිය නොවී සෑම පන්තියකටම තම කාර්යය හොඳින් කිරීමට ඉඩ දීමට ඔබට අවශ්‍යය.

දත්ත ව්‍යුහයක් නිරූපණය කිරීමේ නිවැරදි C # ක්‍රමය කුමක්ද ...

රෙමෙබර්, "සියලුම මාදිලි වැරදියි, නමුත් සමහර ඒවා ප්රයෝජනවත් වේ." - ජෝර්ජ් ඊපී පෙට්ටිය

"නිවැරදි මාර්ගයක්" නොමැත, ප්රයෝජනවත් එකක් පමණි.

ඔබට සහ / ඔබේ පරිශීලකයින්ට ප්‍රයෝජනවත් එකක් තෝරන්න. ඒක තමයි. ආර්ථික වශයෙන් දියුණු වන්න, ඕනෑවට වඩා ඉංජිනේරු නොකරන්න. ඔබ ලියන අඩු කේතය, අඩු කේතයක් ඔබට නිදොස් කිරීමට අවශ්‍ය වේ. (පහත සංස්කරණ කියවන්න).

- සංස්කරණය කරන ලදි

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

- සංස්කරණය 2

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

අනෙක් අතට, ලැයිස්තුවෙන් උරුම කර ගැනීම ප්‍රයෝජනවත් වන අවස්ථා සීමිත සංඛ්‍යාවක් ඇති බව මම විශ්වාස කරමි. මම කලින් සංස්කරණයේ ලියා ඇති පරිදි, එය රඳා පවතී. එක් එක් සිද්ධියට පිළිතුර දැනුම, පළපුරුද්ද සහ පෞද්ගලික මනාපයන් යන දෙකටම බෙහෙවින් බලපායි.

පිළිතුර ගැන වඩාත් නිවැරදිව සිතීමට මට උදව් කිරීම ගැන ai කායිට ස්තූතියි.

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

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

මගේ අපිරිසිදු රහස: මිනිසුන් කියන දේ මට ප්‍රශ්නයක් නොවේ, මම එය කරමි. .NET රාමුව "XxxxCollection" (මගේ ප්‍රධාන උදාහරණය සඳහා UIElementCollection) සමඟ පැතිර ඇත.

ඉතින් මා පවසන දේ නවත්වන්නේ:

team.Players.ByName("Nicolas")

මම එය වඩා හොඳ සොයාගත් විට

team.ByName("Nicolas")

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

club.Players.ByName("Nicolas")

ඊයේ පැවති හොඳම භාවිතයන්, හෙට දවසේ එකක් නොවිය හැකිය. බොහෝ හොඳ භාවිතයන් පිටුපස කිසිදු හේතුවක් නැත, බොහෝ ඒවා ප්‍රජාව අතර පුළුල් එකඟතාවයක් පමණි. ඔබ ඔබෙන්ම එය අසන විට එය ඔබට දොස් පවරයිදැයි ප්‍රජාවෙන් විමසනවා වෙනුවට, වඩා කියවිය හැකි සහ නඩත්තු කළ හැකි දේ කුමක්ද?

team.Players.ByName("Nicolas") 

හෝ

team.ByName("Nicolas")

ඇත්තටම. ඔබට කිසියම් සැකයක් තිබේද? දැන් ඔබේ සැබෑ භාවිතයේදී ලැයිස්තුව <T> භාවිතා කිරීම වලක්වන වෙනත් තාක්ෂණික බාධක සමඟ සෙල්ලම් කිරීමට ඔබට අවශ්‍ය විය හැකිය. නමුත් නොපවතින අවහිරයක් එක් නොකරන්න. මයික්‍රොසොෆ්ට් එයට හේතුව ලේඛනගත නොකළේ නම්, එය නිසැකවම කොතැනකවත් නොපැමිණෙන “හොඳම පුරුද්දකි”.

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

ඔවුන් List<T>"ප්‍රශස්තිකරණය කර ඇති" යැයි පැවසූ විට, එයින් අදහස් කරන්නේ එය වඩා මිල අධික වන අථත්‍ය ක්‍රම වැනි විශේෂාංග නොමැති බවයි. එබැවින් ගැටළුව වන්නේ ඔබ List<T>ඔබේ පොදු API තුළ නිරාවරණය වූ පසු , ව්‍යාපාර නීති බලාත්මක කිරීමට හෝ පසුව එහි ක්‍රියාකාරිත්වය රිසිකරණය කිරීමට ඔබට ඇති හැකියාව නැති වීමයි. නමුත් ඔබ මෙම ව්‍යාපෘතිය තුළ අභ්‍යන්තරව මෙම උරුම පන්තිය භාවිතා කරන්නේ නම් (ඔබේ ගනුදෙනුකරුවන් / හවුල්කරුවන් / වෙනත් කණ්ඩායම් දහස් ගණනක් API ලෙස නිරාවරණය වීමට වඩා වෙනස්ව) එය ඔබගේ කාලය ඉතිරි කර ගන්නේ නම් එය හරි විය හැකි අතර එය ඔබට අවශ්‍ය ක්‍රියාකාරිත්වය වේ අනුපිටපත. එයින් උරුම වීමේ වාසිය List<T>නම්, ඔබ අනාගතයේදී කිසි විටෙකත් අභිරුචිකරණය නොකරන ගොළු රැළි කේත ඉවත් කිරීමයි. ඔබේ පන්තියට නිශ්චිත අර්ථකථන ලබා ගැනීමට ඔබට අවශ්‍ය නම්List<T> ඔබගේ ඒපීඅයි වල ආයු කාලය සඳහා එය හරි විය හැකිය.

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

මෙම පිළිතුරු බොහොමයක් මෙන් මට සංකීර්ණ සංසන්දනයක් නොමැති අතර, මෙම තත්වය හැසිරවීම සඳහා මගේ ක්‍රමය බෙදා ගැනීමට මම කැමතියි. දීර්ඝ IEnumerable<T>, ඔබට ඔබගේ ඉඩ හැක Teamපන්තියේ සියලු ක්රම සහ ගුණ ප්රසිද්ධියේ හෙළි නොකර, Linq විමසුම දිගු සහාය List<T>.

class Team : IEnumerable<Player>
{
    private readonly List<Player> playerList;

    public Team()
    {
        playerList = new List<Player>();
    }

    public Enumerator GetEnumerator()
    {
        return playerList.GetEnumerator();
    }

    ...
}

class Player
{
    ...
}

ඔබේ පන්ති පරිශීලකයින්ට සියලු ක්‍රම සහ ගුණාංග අවශ්‍ය නම් ** ලැයිස්තුවට තිබේ නම්, ඔබ ඔබේ පන්තිය එයින් ලබා ගත යුතුය. ඔවුන්ට ඒවා අවශ්‍ය නොවන්නේ නම්, ලැයිස්තුව කොටු කර ඔබේ පන්ති පරිශීලකයින්ට සැබවින්ම අවශ්‍ය ක්‍රම සඳහා ආවරණ සාදන්න.

ඔබ පොදු API එකක් හෝ බොහෝ අය භාවිතා කරන වෙනත් කේතයක් ලියන්නේ නම් මෙය දැඩි රීතියකි . ඔබට ඉතා කුඩා යෙදුමක් සහ සංවර්ධකයින් 2 කට වඩා නොමැති නම් ඔබට මෙම රීතිය නොසලකා හැරිය හැක. මෙය ඔබට යම් කාලයක් ඉතිරි කර දෙනු ඇත.

ඉතා කුඩා යෙදුම් සඳහා, ඔබ අඩු, අඩු දැඩි භාෂාවක් තෝරා ගැනීම ගැන සලකා බැලිය හැකිය. රූබි, ජාවාස්ක්‍රිප්ට් - අඩු කේත ලිවීමට ඔබට ඉඩ සලසන ඕනෑම දෙයක්.

මට අවශ්‍ය වූයේ අයිෆල් හි නව නිපැයුම්කරු සහ කොන්ත්‍රාත්තුව අනුව නිර්මාණය කළ බර්ට්‍රන්ඩ් මේයර්ට ඇසිපිය නොගැසීමෙන් තොරව Teamඋරුම වනු ඇති බවයි List<Player>.

Object-Oriented Software Construction නම් ඔහුගේ පොතේ, සෘජුකෝණාස්රාකාර කවුළුවලට ළමා කවුළු තිබිය හැකි GUI පද්ධතියක් ක්‍රියාත්මක කිරීම ගැන සාකච්ඡා කරයි. ඔහු හුදෙක් Windowදෙකින්ම උරුම වී ඇති Rectangleඅතර Tree<Window>එය නැවත ක්‍රියාත්මක කිරීම සඳහා ය.

කෙසේ වෙතත්, සී # අයිෆල් නොවේ. දෙවැන්න බහු උරුමය සහ විශේෂාංග නම් කිරීම සඳහා සහාය වේ . C # හි, ඔබ උප පංතියේ සිටින විට, ඔබට අතුරු මුහුණත සහ ක්‍රියාත්මක කිරීම යන දෙකම උරුම වේ. ඔබට ක්‍රියාත්මක කිරීම අභිබවා යා හැක, නමුත් ඇමතුම් සම්මුතීන් සුපිරි පන්තියෙන් කෙලින්ම පිටපත් කරනු ලැබේ. අයිෆල් දී, කෙසේ වෙතත්, ඔබ රාජ්ය ක්රම නම් වෙනස් කළ හැක, එසේ ඔබ නැවත නම් කරන්න පුළුවන් Addසහ Removeකිරීමට Hireහා Fireඔබේ Team. ක උදාහරණයක් නම් Teamකිරීමට upcast ආයෙත් List<Player>, එම දුරකථන ඇමතුම භාවිතා කරනු ඇත Addහා Removeඑය වෙනස් කිරීමට, නමුත් ඔබගේ අතථ්ය ක්රම Hireහා Fireකැඳවනු ලැබේ.

මම හිතන්නේ මම ඔබේ සාමාන්‍යකරණයට එකඟ නැහැ. කණ්ඩායමක් යනු ක්‍රීඩකයන්ගේ එකතුවක් පමණක් නොවේ. කණ්ඩායමක් ඒ පිළිබඳව තවත් බොහෝ තොරතුරු ඇත - නම, ලාංඡනය, කළමනාකරණ / පරිපාලක කාර්ය මණ්ඩලය එකතු කිරීම, පුහුණු කාර්ය මණ්ඩලය එකතු කිරීම, පසුව ක්‍රීඩකයන් එකතු කිරීම. නිසි ලෙස, ඔබේ පාපන්දු කණ්ඩායම පන්තියට එකතු 3 ක් තිබිය යුතු අතර එය එකතුවක් නොවිය යුතුය; එය සැබෑ ලෝකය නිසි ලෙස ආදර්ශනය කිරීමට නම්.

අභ්‍යන්තර වෙළඳසැලෙන් වස්තු එකතු කිරීමට හෝ ඉවත් කිරීමට පෙර වලංගු කිරීම සහ චෙක්පත් වැනි විශේෂිත සංගීත භාණ්ඩ එකතු කිරීම වැනි වෙනත් පහසුකම් සපයන PlayerCollection පන්තියක් ඔබට සලකා බැලිය හැකිය.

සමහර විට, PlayerCollection වඩා හොඳය යන අදහස ඔබ කැමති ප්‍රවේශයට ගැලපේද?

public class PlayerCollection : Collection<Player> 
{ 
}

එවිට පාපන්දු කණ්ඩායම මේ වගේ විය හැකිය:

public class FootballTeam 
{ 
    public string Name { get; set; }
    public string Location { get; set; }

    public ManagementCollection Management { get; protected set; } = new ManagementCollection();

    public CoachingCollection CoachingCrew { get; protected set; } = new CoachingCollection();

    public PlayerCollection Players { get; protected set; } = new PlayerCollection();
}

පන්ති වලට වඩා අතුරු මුහුණත් වලට වැඩි කැමැත්තක් දක්වන්න

පංති පන්ති වලින් ව්‍යුත්පන්න වීම වළක්වා ගත යුතු අතර ඒ වෙනුවට අවශ්‍ය අවම අතුරු මුහුණත් ක්‍රියාත්මක කළ යුතුය.

උරුමය බිඳී යාම එන්කැප්සියුලේෂන්

පංති වලින් ව්‍යුත්පන්න කිරීම සංවෘත කිරීම බිඳ දමයි :

• ඔබේ එකතුව ක්‍රියාත්මක කරන ආකාරය පිළිබඳ අභ්‍යන්තර තොරතුරු හෙළි කරයි
• සුදුසු නොවන අතුරු මුහුණතක් (පොදු කාර්යයන් සහ ගුණාංග සමූහයක්) ප්‍රකාශ කරයි

වෙනත් දේ අතර මෙය ඔබේ කේතය නැවත ප්‍රතිනිර්මාණය කිරීම දුෂ්කර කරයි.

පන්ති යනු ක්‍රියාත්මක කිරීමේ විස්තරයකි

පන්ති යනු ඔබේ කේතයේ වෙනත් කොටස් වලින් සැඟවිය යුතු ක්‍රියාත්මක කිරීමේ විස්තරයකි. කෙටියෙන් කිවහොත්, System.Listවියුක්ත දත්ත වර්ගයක් නිශ්චිතව ක්‍රියාත්මක කිරීමකි, එය දැන් සහ අනාගතයේදී සුදුසු විය හැකිය.

සංකල්පමය වශයෙන් System.Listදත්ත වර්ගය "ලැයිස්තුව" ලෙස හැඳින්වීම රතු හුරුල්ලන් ටිකක් වේ. A System.List<T>යනු විකෘති කළ ඇණවුම් එකතුවක් වන අතර එය මූලද්‍රව්‍ය එකතු කිරීම, ඇතුළත් කිරීම සහ ඉවත් කිරීම සඳහා වූ ක්‍රමක්ෂය කරන ලද O (1) මෙහෙයුම් සඳහා සහ O (1) මූලද්‍රව්‍ය ගණන නැවත ලබා ගැනීම හෝ දර්ශකය අනුව මූලද්‍රව්‍යය ලබා ගැනීම සහ සැකසීම සඳහා වූ මෙහෙයුම් සඳහා සහාය වේ.

කුඩා අතුරුමුහුණත වඩාත් නම්‍යශීලී කේතය

දත්ත ව්‍යුහයක් සැලසුම් කිරීමේදී, අතුරු මුහුණත සරල වන අතර කේතය වඩාත් නම්‍යශීලී වේ. මෙය නිරූපණය කිරීම සඳහා LINQ කෙතරම් බලවත් දැයි බලන්න.

අතුරුමුහුණත් තෝරා ගන්නේ කෙසේද

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

මෙම ක්‍රියාවලිය මෙහෙයවීමට උපකාරී වන ප්‍රශ්න කිහිපයක්:

• මට ගණන් කිරීම අවශ්‍යද? ක්‍රියාත්මක නොකරන්නේ නම්IEnumerable<T>
• මෙම එකතුව ආරම්භ කිරීමෙන් පසු එය වෙනස් වේද? සලකා බැලුවේ නැත්නම් IReadonlyList<T>.
• දර්ශකය අනුව මට අයිතම වෙත ප්‍රවේශ වීම වැදගත් ද? සලකා බලන්නICollection<T>
• මම එකතු කිරීමට අයිතම එකතු කරන අනුපිළිවෙල වැදගත් ද? සමහර විට එය අ ISet<T>?
• ඔබට ඇත්තටම මේ දේ අවශ්‍ය නම් ඉදිරියට ගොස් ක්‍රියාත්මක කරන්න IList<T>.

මේ ආකාරයෙන් ඔබ කේතයේ අනෙක් කොටස් ඔබේ බේස්බෝල් ක්‍රීඩකයන්ගේ එකතුව ක්‍රියාත්මක කිරීමේ විස්තර සමඟ සම්බන්ධ නොකරනු ඇති අතර ඔබ අතුරු මුහුණතට ගරු කරන තාක් කල් එය ක්‍රියාත්මක වන ආකාරය වෙනස් කිරීමට ඔබට නිදහස ඇත.

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

බොයිලර් තහඩුව මග හැරීම පිළිබඳ සටහන්

නවීන IDE එකක අතුරුමුහුණත් ක්‍රියාත්මක කිරීම පහසු විය යුතුය. දකුණු ක්ලික් කර "ක්‍රියාත්මක කිරීමේ අතුරුමුහුණත" තෝරන්න. ඔබට අවශ්‍ය නම් සියලුම ක්‍රියාත්මක කිරීම් සාමාජික පන්තියකට යොමු කරන්න.

එයින් කියැවෙන්නේ ඔබ බොයිලේරු ගොඩක් ලියන බව පෙනේ නම්, එය විය හැකි වන්නේ ඔබ විය යුතු ප්‍රමාණයට වඩා වැඩි කාර්යයන් නිරාවරණය කරන බැවිනි. ඔබ පන්තියකින් උරුම නොවිය යුතු එකම හේතුව එයයි.

ඔබේ යෙදුමට අර්ථවත් වන කුඩා අතුරුමුහුණත් ඔබට සැලසුම් කළ හැකි අතර, ඔබට අවශ්‍ය වෙනත් ඕනෑම කෙනෙකුට එම අතුරුමුහුණත් සිතියම් ගත කිරීම සඳහා උපකාරක ව්‍යාප්ති කිහිපයක් පමණක් කළ හැකිය. ලින්ක්ආරේ පුස්තකාලයIArray සඳහා මගේම අතුරු මුහුණතේ මා ගත් ප්‍රවේශය මෙයයි .

අනුක්‍රමිකකරණය කිරීමේ ගැටළු

එක් අංගයක් අතුරුදහන්. ලැයිස්තුවෙන් උරුම වන පන්ති <> XmlSerializer භාවිතා කර නිවැරදිව අනුක්‍රමික කළ නොහැක . එවැනි අවස්ථාවකදී DataContractSerializer භාවිතා කළ යුතුය, නැතහොත් තමන්ගේම අනුක්‍රමික ක්‍රියාවලියක් අවශ්‍ය වේ.

public class DemoList : List<Demo>
{
    // using XmlSerializer this properties won't be seralized:
    string AnyPropertyInDerivedFromList { get; set; }     
}

public class Demo
{
    // this properties will be seralized
    string AnyPropetyInDemo { get; set; }  
}

වැඩිදුර කියවීම: ලැයිස්තුවක් <> වෙතින් පන්තියක් උරුම වූ විට, XmlSerializer වෙනත් ගුණාංග අනුක්‍රමික නොකරයි

එය පිළිගත හැක්කේ කවදාද?

එරික් ලිපර්ට් උපුටා දැක්වීමට:

ඔබ යාන්ත්‍රණය ගොඩනඟන විට යාන්ත්‍රණය පුළුල් කරයි List<T>.

උදාහරණයක් ලෙස, AddRangeක්‍රමවේදය නොමැති වීමෙන් ඔබ වෙහෙසට පත්ව සිටී IList<T>:

public interface IMoreConvenientListInterface<T> : IList<T>
{
    void AddRange(IEnumerable<T> collection);
}

public class MoreConvenientList<T> : List<T>, IMoreConvenientListInterface<T> { }