কোডটি নীচের মত দেখাচ্ছে:
namespace Test
{
public interface IMyClass
{
List<IMyClass> GetList();
}
public class MyClass : IMyClass
{
public List<IMyClass> GetList()
{
return new List<IMyClass>();
}
}
}
আমি কোড বিশ্লেষণ চালানোর সময় আমি নিম্নলিখিত প্রস্তাবটি পাই।
সতর্কতা 3 CA1002: মাইক্রোসফ্ট.ডিজাইন: সংগ্রহ, রিডঅনলি ক্লেশন বা কীডক্লিকেশন
আমি কীভাবে এটি ঠিক করব এবং এখানে ভাল অনুশীলন কী?
উত্তর:
কেন নয় তা প্রশ্নের "কেন" অংশটির উত্তর দেওয়ার জন্য List<T>, কারণগুলি হ'ল ভবিষ্যত-প্রুফিং এবং এপিআই সরলতা।
ভবিষ্যতে প্রুফিং
List<T>এটি সাবক্লাসিং করে সহজেই বর্ধমান করার জন্য ডিজাইন করা হয়নি; এটি অভ্যন্তরীণ বাস্তবায়নের জন্য দ্রুত হওয়ার জন্য ডিজাইন করা হয়েছে। আপনি লক্ষ্য করবেন যে এতে থাকা পদ্ধতিগুলি ভার্চুয়াল নয় এবং তাই ওভাররাইড করা যাবে না এবং এর Add/ Insert/ Removeক্রিয়াকলাপগুলিতে কোনও হুক নেই ।
এর অর্থ হ'ল যদি আপনাকে ভবিষ্যতে সংগ্রহের আচরণটি পরিবর্তন করতে হয় (যেমন লোকেরা যুক্ত করার চেষ্টা করে এমন নাল বস্তুগুলি প্রত্যাখ্যান করতে, বা যখন আপনার শ্রেণীর অবস্থা আপডেট করার মতো ঘটনা ঘটে তখন অতিরিক্ত কাজ সম্পাদন করা) তবে আপনার ধরণটি পরিবর্তন করতে হবে সংগ্রহের ক্ষেত্রে আপনি সাবক্লাস করতে পারেন এমন একটিতে ফিরে যান, যা একটি ব্রেকিং ইন্টারফেস পরিবর্তন (অবশ্যই নালকে অনুমতি না দেওয়ার মতো জিনিসগুলির শব্দার্থবিজ্ঞান পরিবর্তন করাও একটি ইন্টারফেস পরিবর্তন হতে পারে, তবে আপনার অভ্যন্তরীণ শ্রেণীর অবস্থা আপডেট করার মতো জিনিসগুলি হবে না)।
সুতরাং যে কোনও শ্রেণিকে সহজেই সাবক্লাস করা যেতে পারে যেমন যেমন Collection<T>একটি ইন্টারফেস বা যেমন একটি ইন্টারফেস IList<T>, ICollection<T>বা IEnumerable<T>আপনি নিজের অভ্যন্তরীণ বাস্তবায়নটি আপনার প্রয়োজন মেটাতে আলাদা সংগ্রহের ধরণ হিসাবে পরিবর্তন করতে পারেন, ভোক্তাদের কোড ভঙ্গ না করে কারণ এটি এখনও ফেরত যেতে পারে যে ধরণের তারা আশা করছেন।
এপিআই সরলতা
List<T>যেমন দরকারী অপারেশনের অনেক রয়েছে BinarySearch, Sortইত্যাদি। তবে এটি যদি আপনি সংগ্রহ করছেন তবে এটি সম্ভবত আপনি গ্রাহকদের নয়, তালিকার শব্দার্থবিজ্ঞান নিয়ন্ত্রণ করছেন। সুতরাং আপনার শ্রেণীর অভ্যন্তরীণভাবে এই ক্রিয়াকলাপগুলির প্রয়োজন হতে পারে তবে আপনার শ্রেণীর গ্রাহকরা তাদের কল করতে (বা এমনকি বলা উচিত) খুব কম সম্ভাবনা রয়েছে।
যেমন, একটি সহজ সংগ্রহের ক্লাস বা ইন্টারফেসের প্রস্তাব দিয়ে, আপনি আপনার এপিআই এর ব্যবহারকারীরা যে সদস্য দেখেন তাদের সংখ্যা কমিয়ে দেয় এবং তাদের ব্যবহার সহজ করে তোলে।
আমি ব্যক্তিগতভাবে এটি একটি কংক্রিট সংগ্রহের চেয়ে ইন্টারফেস ফিরিয়ে দেওয়ার জন্য ঘোষণা করব। আপনি যদি সত্যিই তালিকার অ্যাক্সেস চান তবে ব্যবহার করুন IList<T>। অন্যথায়, বিবেচনা করুন ICollection<T>এবং IEnumerable<T>।
We recommend using Collection<T>, ReadOnlyCollection<T>, or KeyedCollection<TKey,TItem> for outputs and properties and interfaces IEnumerable<T>, ICollection<T>, IList<T> for inputs. CA1002 Krzysztof এর মন্তব্যের সাথে বরাবর চলেছে বলে মনে হচ্ছে। ইন্টারফেসের পরিবর্তে কেন একটি কংক্রিট সংগ্রহের প্রস্তাব দেওয়া হবে এবং কেন ইনপুট / আউটপুটগুলির মধ্যে পার্থক্য হবে তা আমি ভাবতে পারি না।
ReadOnlyCollection<T>কোনও ইনপুটটি বোঝায় না। একইভাবে, IList<T>যেমন একটি ইনপুট বলে, "আমার আইআরলিস্টে থাকা বাছাই করা () বা অন্য কোনও সদস্যের প্রয়োজন" যা আউটপুটটির পক্ষে কোনও অর্থ দেয় না। তবে আমি যা বোঝাতে চাইছিলাম তা কেন ICollection<T>ইনপুট Collection<T>হিসাবে এবং আউটপুট হিসাবে সুপারিশ করা হবে । আপনার প্রস্তাব অনুযায়ী আউটপুট হিসাবে ব্যবহার করবেন না কেন ICollection<T>?
Collection<T>এবং ReadOnlyCollection<T>উভয়ই ICollection<T>(যেমন নেই IReadOnlyCollection<T>) থেকে প্রাপ্ত । আপনি যদি ইন্টারফেসটি ফিরিয়ে দেন তবে এটি কোনটি এবং এটি পরিবর্তন করা যায় কিনা তা স্পষ্ট নয়। যাইহোক, আপনার ইনপুট জন্য ধন্যবাদ। এটি আমার জন্য একটি ভাল স্যানিটি পরীক্ষা ছিল।
আমি মনে করি না যে কেউ "কেন" অংশটি এখনও জবাব দিয়েছে ... তাই এখানে যায়। এর Collection<T>পরিবর্তে "কেন" আপনার "ব্যবহার করা উচিত List<T>কারণ আপনি যদি কোনওটিকে প্রকাশ করেন List<T>তবে যে কেউ আপনার বস্তুর অ্যাক্সেস পায় সে তালিকার আইটেমগুলিকে সংশোধন করতে পারে। যেখানে Collection<T>আপনি নিজের "অ্যাড", "সরান", ইত্যাদি পদ্ধতিগুলি ইঙ্গিত করছেন বলে ধারণা করা হচ্ছে।
আপনার সম্ভবত এটি নিয়ে মাথা ঘামানোর দরকার নেই, কারণ আপনি সম্ভবত নিজের জন্য ইন্টারফেস কোডিং করছেন (বা সম্ভবত কয়েকটি কলেজ)। এখানে অন্য একটি উদাহরণ রয়েছে যা বোধগম্য হতে পারে।
আপনার যদি সর্বজনীন অ্যারে থাকে তবে প্রাক্তন:
public int[] MyIntegers { get; }আপনি ভাববেন যে কারণ কেবলমাত্র "গেট" অ্যাক্সেসর রয়েছে যে কেউ মানগুলির সাথে গণ্ডগোল করতে পারে না, তবে এটি সত্য নয়। যে কোনও ব্যক্তি ভিতরে মানগুলি এইভাবে পরিবর্তন করতে পারে:
someObject.MyIngegers[3] = 12345;ব্যক্তিগতভাবে, আমি কেবল List<T>বেশিরভাগ ক্ষেত্রেই ব্যবহার করব । তবে আপনি যদি কোনও শ্রেণিবদ্ধ গ্রন্থাগার ডিজাইন করেন যা আপনি এলোমেলো বিকাশকারীদের দিতে চলেছেন, এবং আপনাকে অবজেক্টগুলির অবস্থার উপর নির্ভর করতে হবে ... তবে আপনি নিজের সংগ্রহ তৈরি করতে এবং সেখান থেকে এটি লক করে রাখতে চাইবেন: )
এটি বেশিরভাগ ক্ষেত্রে নিজের প্রয়োগগুলি বিমূর্ত করার বিষয়ে তালিকার অবজেক্টটি সরাসরি ম্যানিপুলেটেড করার পরিবর্তে প্রকাশের পরিবর্তে about
অন্যান্য বস্তুগুলিকে (বা লোকেরা) সরাসরি আপনার সামগ্রীর অবস্থা পরিবর্তন করতে দেওয়া ভাল অনুশীলন নয়। সম্পত্তি গেটার / সেটেটরগুলি ভাবেন।
সংগ্রহ -> সাধারণ সংগ্রহের
জন্য
পড়ুনআপনি সংগ্রহ -> যে সংকলনগুলির কেইডক্লিকেশনটি সংশোধন করা উচিত নয় -> আপনি যখন এর পরিবর্তে অভিধান চান তখন।
কীভাবে এটি ঠিক করবেন আপনি আপনার ক্লাসটি কী করতে চান এবং গেটলিস্ট () পদ্ধতির উদ্দেশ্য এর উপর নির্ভর করে। তুমি কি বিস্তারিত বলতে পারো?
ReadOnlyCollectionঅন্য দুজনকে বাদ দিয়ে তা মানা হয় না।
GetList()তাকে আরও সঠিকভাবে সহায়তা করতে সক্ষম হওয়ার উদ্দেশ্য সম্পর্কে তাকে জিজ্ঞাসা করি ।
Collection<T>অভ্যন্তরীণ বাস্তবায়ন বিমূর্ত করতে সহায়তা করে এবং অভ্যন্তরীণ তালিকার সরাসরি কারচুপি রোধ করে। কিভাবে? Collection<T>নিছক একটি মোড়ক, একই ঘটনায় অপারেটিং পাস। এটি উত্তরাধিকারের জন্য গতিশীল সংগ্রহ, অন্য কিছু নয় (গ্রেগের উত্তর এখানে আরও প্রাসঙ্গিক)।
এই ধরণের ক্ষেত্রে আমি সাধারণত কমপক্ষে কতটা প্রয়োগের প্রয়োজন তা প্রকাশ করার চেষ্টা করি। যদি ভোক্তাদের যদি জানতে প্রয়োজন হয় না যে আপনি আসলে একটি তালিকা ব্যবহার করছেন তবে আপনাকে কোনও তালিকা ফেরত দেওয়ার দরকার নেই। মাইক্রোসফ্ট কোনও সংগ্রহের পরামর্শ দেওয়ার সাথে সাথে ফিরে এসে আপনি এই সত্যটি লুকিয়ে রাখেন যে আপনি নিজের শ্রেণীর গ্রাহকদের কাছ থেকে একটি তালিকা ব্যবহার করছেন এবং কোনও অভ্যন্তরীণ পরিবর্তনের বিরুদ্ধে এগুলি আলাদা করে দিন।
এটি জিজ্ঞাসা করার পরে অনেক দিন হয়ে গেলেও কিছু যুক্ত করার জন্য।
থেকে আপনার তালিকা টাইপ আহরিত যখন List<T>পরিবর্তে Collection<T>, আপনি সংরক্ষিত ভার্চুয়াল পদ্ধতি বাস্তবায়ন করতে পারবে না Collection<T>প্রয়োগ করা হয়। এর অর্থ হ'ল তালিকায় কোনও পরিবর্তন আনার ক্ষেত্রে আপনি প্রাপ্ত টাইপটি প্রতিক্রিয়া জানাতে পারবেন না। এর কারণ এটি List<T>ধরে নেওয়া হয় যে আপনি যখন আইটেমগুলি যুক্ত করেন বা সরিয়ে রাখেন তখন আপনি সচেতন হন। বিজ্ঞপ্তিগুলির প্রতিক্রিয়া জানাতে সক্ষম হওয়াই একটি ওভারহেড এবং তাই এটি সরবরাহ List<T>করে না।
যখন বাহ্যিক কোডের আপনার সংগ্রহে অ্যাক্সেস রয়েছে তখন আপনি যখন কোনও আইটেম যুক্ত বা অপসারণ করছেন তখন আপনি নিয়ন্ত্রণে রাখতে পারবেন না। সুতরাং Collection<T>আপনার তালিকাটি কখন সংশোধন করা হয়েছে তা জানার একটি উপায় সরবরাহ করে।
এরকম কিছু ফেরাতে আমি কোনও সমস্যা দেখছি না
this.InternalData.Filter(crteria).ToList();যদি আমি অভ্যন্তরীণ তথ্যগুলির একটি সংযোগ বিহীন অনুলিপি , বা কোনও ডেটা ক্যোয়ারীর বিচ্ছিন্ন ফলাফলটি ফিরিয়ে দিয়েছি - তবে আমি List<TItem>প্রয়োগের কোনও বিবরণ প্রকাশ না করে নিরাপদে ফিরে আসতে পারি এবং সুবিধাজনক উপায়ে ফিরে আসা ডেটা ব্যবহার করার অনুমতি দিতে পারি।
তবে এটি নির্ভর করে আমি কী ধরণের গ্রাহক আশা করি - এটি যদি ডেটা গ্রিডের মতো কিছু হয় তবে আমি ফিরে যেতে পছন্দ করি IEnumerable<TItem> যা বেশিরভাগ ক্ষেত্রে আইটেমের অনুলিপি তালিকা হতে পারে :)
ঠিক আছে সংগ্রহ শ্রেণিটি অন্যান্য সংগ্রহগুলির বাস্তব প্রয়োগের বিশদ এবং অন্যান্য বৈশিষ্ট্যগুলি গোপন করার জন্য কেবল একটি মোড়কের ক্লাস। আমি বিবেচনা করি এর সাথে সম্পত্তি সম্পর্কিত গোপন কোডিং প্যাটার্নটি অবজেক্ট ভিত্তিক ভাষাগুলির সাথে কিছু করার আছে।
আমি মনে করি আপনার এটি নিয়ে চিন্তা করা উচিত নয়, তবে আপনি যদি কোড বিশ্লেষণ সরঞ্জামটি সত্যিই খুশি করতে চান তবে কেবল নিম্নলিখিতটি করুন:
//using System.Collections.ObjectModel;
Collection<MyClass> myCollection = new Collection<MyClass>(myList);Collection<T>না যতটা আমি বুঝতে পেরেছি নিজেকে বা অন্তর্নিহিত সংগ্রহ না রক্ষা করে।
Collection<T>তাত্ক্ষণিকভাবে আপনার অন্তর্নিহিত সংগ্রহকে সুরক্ষিত করবে।