Iterator প্যাটার্ন - কেন অভ্যন্তরীণ উপস্থাপনা প্রকাশ না করা গুরুত্বপূর্ণ?

Question

আমি পড়া করছি C # এর নকশা প্যাটার্ন এসেনশিয়ালস । আমি বর্তমানে পুনরাবৃত্তি প্যাটার্ন সম্পর্কে পড়ছি।

আমি কীভাবে প্রয়োগ করব তা পুরোপুরি বুঝতে পেরেছি, তবে আমি গুরুত্ব বুঝতে পারি না বা ব্যবহারের ক্ষেত্রেও দেখতে পাই না। বইটিতে এমন একটি উদাহরণ দেওয়া হয়েছে যেখানে কারও কাছে অবজেক্টের একটি তালিকা পাওয়া দরকার। তারা কোনও সরকারী সম্পত্তি যেমন IList<T>বা একটি হিসাবে প্রকাশ করে এটি করতে পারত Array।

বইটি লিখেছেন

এটির সাথে সমস্যাটি হ'ল এই উভয় শ্রেণির অভ্যন্তরীণ উপস্থাপনা বাইরের প্রকল্পগুলির কাছে প্রকাশিত হয়েছে।

অভ্যন্তরীণ উপস্থাপনা কি? আসলে এটি একটি arrayবা IList<T>? আমি সত্যিই বুঝতে পারি না কেন এটি কেন গ্রাহক (প্রোগ্রামার এটিকে কল করছে) এটি জানার জন্য খারাপ জিনিস ...

তারপরে বইটি বলেছে যে এই প্যাটার্নটি এর GetEnumeratorফাংশনটি প্রকাশ করে কাজ করে, তাই আমরা কল করে GetEnumerator()এইভাবে 'তালিকা' প্রকাশ করতে পারি ।

আমি ধরে নিই যে কিছু পরিস্থিতিতে এই নিদর্শনগুলির একটি জায়গা রয়েছে (সকলের মতো) তবে আমি কোথায় এবং কখন তা দেখতে ব্যর্থ হই।

Comments

আরও পঠন: en.m.wikedia.org/wiki/Law_of_Demeter

— জুলস

কারণ, প্রয়োগটি গ্রাহক শ্রেণীর পরিবর্তনের প্রয়োজন ছাড়াই কোনও অ্যারে ব্যবহার থেকে কোনও লিঙ্কযুক্ত তালিকা ব্যবহার করতে পরিবর্তিত হতে পারে। গ্রাহক সঠিক ক্লাসটি কীভাবে ফিরেছেন তা যদি জানা থাকে তবে এটি অসম্ভব।

— এমটিস্টल्ड

এটা তোলে জন্য ভোক্তা করার জন্য একটি খারাপ জিনিস নয় জানি , এটা ভোক্তা করার জন্য একটি খারাপ জিনিস উপর নির্ভর । তথ্য-গোপনীয়তা শব্দটি আমি পছন্দ করি না কারণ এটি আপনাকে বিশ্বাস করতে পরিচালিত করে যে তথ্যটি আপনার পাসওয়ার্ডের মতো ফোনের অভ্যন্তরের মতো নয় "ব্যক্তিগত"। অভ্যন্তরীণ উপাদানগুলি লুকানো আছে কারণ তারা ব্যবহারকারীর কাছে অপ্রাসঙ্গিক, কারণ তারা কোনও ধরণের গোপনীয়তা নয়। আপনার যা জানা দরকার তা হ'ল এখানে ডায়াল করুন, এখানে কথা বলুন, এখানে শুনুন।

— ক্যাপ্টেন ম্যান

ধরুন যে আমরা একটা চমৎকার "ইন্টারফেস" have Fআমার জ্ঞান (পদ্ধতি) দেয় a, bএবং c। সবকিছু ঠিকঠাক এবং ভাল, অনেক কিছুই থাকতে পারে যা আলাদা তবে কেবল Fআমার কাছে। পদ্ধতিটিকে "সীমাবদ্ধতা" হিসাবে মনে করুন বা কোনও চুক্তির ধারাগুলি Fক্লাস করার জন্য প্রতিশ্রুতিবদ্ধ। মনে করুন যে আমরা কিছুটা যুক্ত করেছি dকারণ এটি আমাদের প্রয়োজন। এটি অতিরিক্ত বাধা যুক্ত করে, প্রতিবার আমরা যখন এটি করি তখন আমরা এসকে আরও বেশি চাপিয়ে দেই F। অবশেষে (সবচেয়ে খারাপ ক্ষেত্রে) কেবলমাত্র একটি জিনিস হতে পারে Fতাই আমরা এটি নাও পেতে পারি। এবং Fএতটা বাধা আছে এটি করার একমাত্র উপায় way

— আলেক টিল

@ ক্যাপিটেনম্যান, কি দুর্দান্ত মন্তব্য। হ্যাঁ, আমি কেন অনেক কিছুই 'বিমূর্ত' করতে দেখছি, তবে জানার এবং নির্ভর করার বিষয়ে টুইস্টটি হ'ল ... স্পষ্টতই .... উজ্জ্বল। এবং একটি গুরুত্বপূর্ণ পার্থক্য যা আমি আপনার পোস্ট না পড়া পর্যন্ত বিবেচনা করি নি।

— MyDaftQuestions

Answer 1

সফটওয়্যারটি প্রতিশ্রুতি এবং সুবিধাগুলির একটি খেলা। আপনি যে পরিমাণ সরবরাহ করতে পারেন তার চেয়ে বেশি বা আপনার সহযোগীর প্রয়োজনের চেয়ে বেশি প্রতিশ্রুতি দেওয়া কখনই ভাল ধারণা নয়।

এটি প্রকারভেদে বিশেষত প্রযোজ্য। একটি পুনরাবৃত্তযোগ্য সংগ্রহ লেখার মূল বিষয় হ'ল এর ব্যবহারকারী এটির উপরে পুনরাবৃত্তি করতে পারে - আর নেই, কম নয়। দেশবাসীর কাছে মুখোশ উম্মোচন কংক্রিট টাইপ Arrayসাধারণত অনেক অতিরিক্ত প্রতিশ্রুতি, যেমন আপনি আপনার নিজের পছন্দসই একটি ফাংশন দ্বারা সংগ্রহ সাজাতে পারেন যে একটি স্বাভাবিক উল্লেখ না সৃষ্টি Arrayইচ্ছার সম্ভবত সহযোগী করার অনুমতি দেয় পরিবর্তন এটি ভিতরে সঞ্চিত ডেটা।

এমনকি যদি আপনি এটি একটি ভাল জিনিস বলে মনে করেন ("যদি রেন্ডারার লক্ষ্য করে যে নতুন রফতানির বিকল্পটি অনুপস্থিত রয়েছে, তবে এটি কেবল এটি সঠিকভাবে প্যাচ করতে পারে!") সামগ্রিকভাবে এটি কোড বেসের সুসংহতিকে হ্রাস করে, এটি আরও শক্ত করে তোলে making সম্পর্কে কারণ - এবং কোডটি সহজেই কারণ হিসাবে তৈরি করা সফ্টওয়্যার ইঞ্জিনিয়ারিংয়ের সর্বাধিক লক্ষ্য।

এখন, যদি আপনার সহযোগী বেশ কয়েকটি জিনিসপত্রের অ্যাক্সেসের প্রয়োজন হয় যাতে সেগুলির কোনওটিই মিস না করার গ্যারান্টিযুক্ত হয় তবে আপনি একটি Iterableইন্টারফেস প্রয়োগ করেন এবং এই ইন্টারফেসটি যে ঘোষণা করে কেবল সেগুলিই উদ্ভাসিত করে। এইভাবে, পরের বছর যখন আপনার স্ট্যান্ডার্ড লাইব্রেরিতে একটি বৃহত্তর আরও ভাল এবং আরও দক্ষ ডেটা কাঠামো উপস্থিত হয়, আপনি কোথাও আপনার ক্লায়েন্ট কোডটি স্থির না করেই অন্তর্নিহিত কোডটি স্যুইচ আউট করতে এবং সেখান থেকে উপকার পেতে সক্ষম হবেন । প্রয়োজনের চেয়ে বেশি প্রতিশ্রুতি না দেওয়ার অন্যান্য সুবিধাগুলি রয়েছে তবে এটি একা এতটাই বড় যে বাস্তবে, অন্য কারও প্রয়োজন হয় না।

Comments

Exposing the concrete type Array usually creates many additional promises, e.g. that you can sort the collection by a function of your own choosing...- উজ্জ্বল। আমি শুধু এটি ভেবে দেখিনি। হ্যাঁ, এটি একটি 'পুনরাবৃত্তি' এবং কেবল, একটি পুনরাবৃত্তি ফিরিয়ে আনে!

— MyDaftQuestions

Answer 2

বাস্তবায়নটি আড়াল করা হ'ল ওওপির মূল নীতি এবং সমস্ত দৃষ্টান্তে একটি ভাল ধারণা, তবে অলস পুনরাবৃত্তি সমর্থন করে এমন ভাষাগুলিতে এটির পুনরাবৃত্তিকারীদের (বা তারা যে নির্দিষ্ট ভাষায় যা বলা হয়) বিশেষত এটি গুরুত্বপূর্ণ।

কংক্রিটের ধরণের পুনরাবৃত্তিগুলি - বা এমনকি ইন্টারফেসের মতো প্রকাশের ক্ষেত্রে যে সমস্যাগুলি তাদের প্রকাশ করে IList<T>তা নয়, তবে যে পদ্ধতিগুলি সেগুলি ব্যবহার করে সেগুলিতে। উদাহরণস্বরূপ, আসুন ধরা যাক যে এর একটি তালিকা মুদ্রণের জন্য আপনার একটি ফাংশন রয়েছে Foo:

void PrintFoos(IList<Foo> foos)
{
    foreach (foo in foos)
    {
        Console.WriteLine(foo);
    }
}

আপনি কেবলমাত্র ফু এর তালিকাগুলি মুদ্রণের জন্য সেই ফাংশনটি ব্যবহার করতে পারেন - তবে কেবলমাত্র তারা প্রয়োগ করে IList<Foo>

IList<Foo> foos = //.....
PrintFoos(foos);

তবে আপনি যদি তালিকার প্রতিটি সম-সূচক আইটেমটি মুদ্রণ করতে চান ? আপনার একটি নতুন তালিকা তৈরি করতে হবে:

IList<Foo> everySecondFoo = new List<T>();
bool isIndexEven = true;
foreach (foo; foos)
{
    if (isIndexEven)
    {
        everySecondFoo.Add(foo);
    }
    isIndexEven = !isIndexEven;
}
PrintFoos(everySecondFoo);

এটি বেশ দীর্ঘ, তবে লিনকিউ দিয়ে আমরা এটি ওয়ান-লাইনারে করতে পারি, যা আসলে আরও পাঠযোগ্য:

PrintFoos(foos.Where((foo, i) => i % 2 == 0).ToList());

এখন, আপনি কি .ToList()শেষ পর্যন্ত খেয়াল করেছেন ? এটি অলস ক্যোয়ারিকে একটি তালিকায় রূপান্তর করে, তাই আমরা এটিতে প্রেরণ করতে পারি PrintFoos। এটির জন্য দ্বিতীয় তালিকার একটি বরাদ্দ প্রয়োজন, এবং আইটেমগুলিতে দুটি পাস (দ্বিতীয় তালিকাগুলি তৈরির জন্য প্রথম তালিকার একটি এবং অন্যটি মুদ্রণের জন্য দ্বিতীয় তালিকায়)। এছাড়াও, আমাদের যদি এটি থাকে তবে:

void Print6Foos(IList<Foo> foos)
{
    int counter = 0;
    foreach (foo in foos)
    {
        Console.WriteLine(foo);
        ++ counter;
        if (6 < counter)
        {
            return;
        }
    }
}

// ........

Print6Foos(foos.Where((foo, i) => i % 2 == 0).ToList());

foosহাজারে এন্ট্রি থাকলে কী হবে ? আমাদের সেগুলির মধ্যে দিয়ে যেতে হবে এবং তাদের 6 টি মুদ্রণের জন্য একটি বিশাল তালিকা বরাদ্দ করতে হবে!

উল্লিখিত প্যাটার্নের সি # এর সংস্করণ লিখুন। আমাদের ফাংশনটি কোনও তালিকা গ্রহণ করার পরিবর্তে, আমরা এটিকে গ্রহণ করি Enumerable:

void Print6Foos(Enumerable<Foo> foos)
{
    // everything else stays the same
}

// ........

Print6Foos(foos.Where((foo, i) => i % 2 == 0));

এখন Print6Foosতালিকার প্রথম 6 টি আইটেমটি অলসভাবে পুনরাবৃত্তি করতে পারে এবং আমাদের এটির বাকীটি স্পর্শ করার দরকার নেই।

অভ্যন্তরীণ উপস্থাপনা প্রকাশ না করা এখানে মূল বিষয়। Print6Foosকোনও তালিকা গৃহীত হলে , আমাদের এটিকে একটি তালিকা দিতে হয়েছিল - এমন কিছু যা এলোমেলো অ্যাক্সেসকে সমর্থন করে - এবং তাই আমাদের একটি তালিকা বরাদ্দ করতে হয়েছিল, কারণ স্বাক্ষরটি গ্যারান্টি দেয় না যে এটি কেবল এটির উপর পুনরাবৃত্তি করবে। বাস্তবায়নটি আড়াল করে, আমরা সহজেই আরও কার্যকর দক্ষ Enumerableঅবজেক্ট তৈরি করতে পারি যা ফাংশনটি আসলে যা প্রয়োজন তা সমর্থন করে।

Answer 3

অভ্যন্তরীণ উপস্থাপনাকে প্রকাশ করা কার্যত কখনই ভাল ধারণা নয়। এটি কেবল কোড সম্পর্কে যুক্তিযুক্ত হতে শক্ত করে না, তবে এটি বজায় রাখাও আরও কঠিন। কল্পনা করুন যে আপনি কোনও অভ্যন্তরীণ প্রতিনিধিত্ব বেছে নিয়েছেন - একটি বলি IList<T>- এবং এই অভ্যন্তরীণটিকে উন্মুক্ত করে। আপনার কোড ব্যবহার করে যে কেউ তালিকাতে অ্যাক্সেস করতে পারে এবং কোডটি তালিকা হিসাবে অভ্যন্তরীণ উপস্থাপনার উপর নির্ভর করতে পারে।

যে কারণেই আপনি অভ্যন্তরীণ প্রতিনিধিত্বকে IAmWhatever<T>পরে কোনও সময়ে পরিবর্তন করার সিদ্ধান্ত নিচ্ছেন । কেবল আপনার শ্রেণীর ইন্টার্নালগুলি পরিবর্তনের পরিবর্তে আপনাকে অভ্যন্তরীণ উপস্থাপনার উপর নির্ভর করে প্রতিটি কোড এবং পদ্ধতিতে পরিবর্তন করতে হবে IList<T>। এটি ক্লাসিকর এবং সর্বোত্তম ত্রুটিগুলির প্রবণ, যখন আপনি কেবল ক্লাসটি ব্যবহার করছেন তবে এটি আপনার শ্রেণি ব্যবহার করে অন্যান্য লোকের কোডটি ভেঙে দিতে পারে। যদি আপনি কেবল কোনও অভ্যন্তরীণ প্রকাশ না করেই জনসাধারণের একটি সেটকে উন্মোচিত করে থাকেন তবে আপনি কোনও শ্রেণি নোটিশ না নিয়ে আপনার শ্রেণীর বাইরে কোডের কোনও লাইন ছাড়াই অভ্যন্তরীণ উপস্থাপনাকে পরিবর্তন করতে পারতেন, যেন কিছুই পরিবর্তন হয়নি।

এ কারণেই এনক্যাপসুলেশন কোনও অনিয়ন্ত্রিত সফ্টওয়্যার ডিজাইনের অন্যতম গুরুত্বপূর্ণ বিষয় of

Answer 4

আপনি যত কম বলবেন ততই কম বলতে হবে।

আপনি যত কম জিজ্ঞাসা করবেন, আপনাকে তত কম বলা হবে।

যদি আপনার কোডটি কেবল এক্সপোজ করে IEnumerable<T>, যা কেবল সমর্থন করে GetEnumrator()এটি সমর্থন করতে পারে এমন অন্য কোনও কোড দ্বারা প্রতিস্থাপিত হতে পারে IEnumerable<T>। এটি নমনীয়তা যুক্ত করে।

যদি আপনার কোডটি কেবল IEnumerable<T>এটি ব্যবহার করে তবে কার্যকর হয় এমন কোনও কোড দ্বারা এটি সমর্থন করা যেতে পারে IEnumerable<T>। আবার অতিরিক্ত নমনীয়তাও রয়েছে।

উদাহরণস্বরূপ লিনাক-টু-অবজেক্টগুলির সমস্তই কেবল নির্ভর করে IEnumerable<T>। যদিও এটি কিছু নির্দিষ্ট বাস্তবায়ন দ্রুতগতিতে IEnumerable<T>এটি পরীক্ষা-ও ব্যবহারের পথে এটি করে যা সর্বদা স্রেফ ব্যবহার GetEnumerator()এবং ফলস্বরূপ IEnumerator<T>বাস্তবায়নে ফ্যালব্যাক করতে পারে । এটি অ্যারে বা তালিকার শীর্ষে নির্মিত হলে তার চেয়ে অনেক বেশি নমনীয়তা দেয়।

Comments

সুন্দর পরিষ্কার উত্তর। আপনি এটিকে সংক্ষিপ্ত রেখেছেন এবং খুব ভালভাবেই প্রথম বাক্যে আপনার পরামর্শ অনুসরণ করুন। বলিহারি!

— ড্যানিয়েল হোলিনরেকে

Answer 5

আমি একটি শব্দ যা আয়নাগুলি ব্যবহার করতে চাই @ ক্যাপিটম্যানের মন্তব্য: "গ্রাহকের পক্ষে অভ্যন্তরীণ বিবরণগুলি জানা ভাল। গ্রাহকের পক্ষে অভ্যন্তরীণ বিবরণগুলি জানা উচিত এটি খারাপ " "

যদি কোনও গ্রাহককে টাইপ করতে হয় arrayবা IList<T>তাদের কোড লিখতে হয়, যখন এই ধরণের অভ্যন্তরীণ বিবরণ ছিল, গ্রাহককে অবশ্যই তাদের সঠিকভাবে পেতে হবে । যদি সেগুলি ভুল হয় তবে গ্রাহক সংকলন করতে পারে না, বা ভুল ফলাফলও পেতে পারে। এটি অন্যান্য উত্তরগুলির মতো একই আচরণের ফল দেয় "সর্বদা বাস্তবায়ন বিশদটি গোপন করুন কারণ আপনার এগুলি প্রকাশ করা উচিত নয়", তবে প্রকাশ না করার সুবিধাগুলি খনন করতে শুরু করে। আপনি যদি কখনও প্রয়োগের বিশদটি প্রকাশ না করেন তবে আপনার গ্রাহক এটিকে ব্যবহার করে কখনই নিজেকে আবদ্ধ করতে পারবেন না!

আমি এই আলোকে এটিকে ভাবতে পছন্দ করি কারণ এটি বাস্তবতার অর্থগুলি ছায়াছবিতে ছদ্মবেশ ধারণ করার পরিবর্তে অর্থাত্ ছদ্মবেশী "সর্বদা আপনার প্রয়োগের বিবরণ গোপন করে"। এমন প্রচুর পরিস্থিতি রয়েছে যেখানে প্রকাশের বাস্তবায়ন সম্পূর্ণ বৈধ valid রিয়েল টাইম ডিভাইস ড্রাইভারদের ক্ষেত্রে বিবেচনা করুন, যেখানে বিমূর্ততার অতীত স্তরগুলি এড়িয়ে যাওয়ার এবং সঠিক জায়গায় বাইটগুলি পোকে দেওয়ার ক্ষমতা সময় নির্ধারণের সময় না করার পার্থক্য হতে পারে। বা এমন একটি বিকাশের পরিবেশ বিবেচনা করুন যেখানে আপনার কাছে "ভাল এপিআই" তৈরি করার সময় নেই এবং অবিলম্বে জিনিসগুলি ব্যবহারের প্রয়োজন। প্রায়শই এই জাতীয় পরিবেশে অন্তর্নিহিত API গুলি প্রকাশ করা একটি সময়সীমা তৈরির সময় না পার্থক্য হতে পারে।

যাইহোক, আপনি এই বিশেষ কেসগুলি পিছনে রেখে যান এবং আরও সাধারণ কেসগুলিতে তাকান, এটি বাস্তবায়নকে আড়াল করার জন্য আরও বেশি গুরুত্বপূর্ণ হয়ে উঠতে শুরু করে। বাস্তবায়নের বিশদটি প্রকাশ করা দড়ির মতো। যথাযথভাবে ব্যবহার করা হলে আপনি এর সাথে সমস্ত ধরণের জিনিস যেমন লম্বা পাহাড়কে স্কেল করতে পারেন। অযথা ব্যবহার করা হয়েছে, এবং এটি আপনাকে একটি ফাঁদে বাঁধতে পারে। আপনার পণ্য কীভাবে ব্যবহার করা হবে সে সম্পর্কে আপনি যত কম জানেন, আপনার তত বেশি সতর্ক হওয়া দরকার।

কেস স্টাডি যা আমি সময় এবং সময়কে আবার দেখতে পাই সেগুলি হ'ল যেখানে একজন বিকাশকারী এমন একটি এপিআই তৈরি করে যা প্রয়োগের বিবরণ গোপনে খুব যত্নশীল নয়। দ্বিতীয় বিকাশকারী, সেই লাইব্রেরিটি ব্যবহার করে, আবিষ্কার করে যে এপিআই তাদের পছন্দসই কিছু মূল বৈশিষ্ট্য অনুপস্থিত। বৈশিষ্ট্যের অনুরোধটি লেখার পরিবর্তে (যা কয়েক মাসের টার্নআরন্ড সময় থাকতে পারে) পরিবর্তে তারা গোপন বাস্তবায়নের বিশদগুলিতে তাদের অ্যাক্সেসের অপব্যবহার করার পরিবর্তে সিদ্ধান্ত নেয় (যা কয়েক সেকেন্ড সময় নেয়)। এটি নিজে এবং নিজের পক্ষে খারাপ নয়, তবে প্রায়শই এপিআই বিকাশকারী কখনও এপিআইয়ের অংশ হওয়ার পরিকল্পনা করেনি। পরে, যখন তারা এপিআই উন্নত করে এবং সেই অন্তর্নিহিত বিশদটি পরিবর্তন করে, তারা দেখতে পায় যে তারা পুরানো প্রয়োগের সাথে বেঁধে রয়েছে, কারণ কেউ এপিআইয়ের অংশ হিসাবে এটি ব্যবহার করেছে। এর নিকৃষ্টতম সংস্করণ হ'ল গ্রাহককেন্দ্রিক বৈশিষ্ট্য সরবরাহ করতে কেউ আপনার এপিআই ব্যবহার করেছে এবং এখন আপনার সংস্থা ' এই ত্রুটিযুক্ত এপিআইয়ের সাথে পে-চেক বাঁধা! কেবলমাত্র যখন আপনি আপনার গ্রাহকদের সম্পর্কে পর্যাপ্ত পরিমাণে জানতেন না তখন বাস্তবায়নের বিশদটি প্রকাশ করে আপনার API এর চারপাশে কোনও ফাঁদ বাঁধতে যথেষ্ট দড়ি হিসাবে প্রমাণিত হয়েছিল!

Comments

পুনরায়: "বা এমন উন্নয়নের পরিবেশ বিবেচনা করুন যেখানে আপনার কাছে 'ভাল এপিআই' তৈরি করার সময় নেই, এবং অবিলম্বে জিনিসগুলি ব্যবহার করা দরকার": আপনি যদি এমন পরিবেশে নিজেকে খুঁজে পান এবং কোনও কারণে ছাড়তে চান না ( বা নিশ্চিত না হন তবে), আমি ডেথ মার্চ বইটি সুপারিশ করছি : 'মিশন ইম্পসিবল' প্রকল্পগুলি থেকে বেঁচে থাকার জন্য সম্পূর্ণ সফটওয়্যার বিকাশকারী গাইড । এটি বিষয়ে চমৎকার পরামর্শ আছে। (এছাড়াও, আমি আপনাকে

— অব্যাহতি

@ruakh আমি খুঁজে পেয়েছি যে এমন পরিবেশে কীভাবে কাজ করবেন যেখানে আপনার ভাল API তৈরি করার সময় নেই। সত্যি বলতে, আমরা আইভরি টাওয়ারের পদ্ধতির যতটা ভালোবাসি, বাস্তব কোডটি আসলে বিলগুলি প্রদান করে। যত তাড়াতাড়ি আমরা স্বীকার করতে পারি, যত তাড়াতাড়ি আমরা আমাদের সঠিক পরিবেশের সাথে মেলে উত্পাদনশীল কোডের সাথে এপিআই মানের ভারসাম্য বজায় রেখে ভারসাম্য হিসাবে সফটওয়্যারটির কাছে যেতে শুরু করতে পারি। আমি অনেক তরুণ বিকাশকারীকে দেখেছি আদর্শের জগতে আটকা পড়েছি, বুঝতে পারছি না যে তাদের নমনীয় করার দরকার আছে। (আমি সেই তরুণ বিকাশকারীও হয়েছি .. এখনও 5 বছর "ভাল এপিআই" ডিজাইন থেকে সেরে

— উঠছি

রিয়েল কোডগুলি বিলগুলি প্রদান করে, হ্যাঁ। ভাল এপিআই নকশা হ'ল আপনি কীভাবে নিশ্চিত হন যে আপনি বাস্তব কোড উত্পন্ন করতে চালিয়ে যাবেন। ক্রেপি কোড নিজেই অর্থ প্রদান বন্ধ করে দেয় যখন কোনও প্রকল্প অনিবার্য হয়ে যায় এবং নতুনগুলি তৈরি না করে বাগগুলি ঠিক করা অসম্ভব হয়ে পড়ে। (এবং যাহাই হউক না কেন, এই একটি মিথ্যা উভয়সঙ্কট কি ভাল কোড প্রয়োজন হয় না। সময় যেমন এত মেরুদন্ড ।)

— ruakh

@রুখ আমি যা পেয়েছি তা হ'ল "ভাল এপিআই" ছাড়াই ভাল কোড তৈরি করা সম্ভব। যদি সুযোগ দেওয়া হয় তবে ভাল এপিআইগুলি দুর্দান্ত, তবে তাদের প্রয়োজনীয়তার হিসাবে বিবেচনা করা তার পক্ষে মূল্যমানের চেয়ে বেশি কলহের কারণ হয়। বিবেচনা করুন: মানবদেহের জন্য এপিআই ভয়ঙ্কর, তবে আমরা এখনও মনে করি তারা ইঞ্জিনিয়ারিংয়ের খুব ভাল সামান্য কৌতুক =)

— কর্ট অ্যামোন -

আমি যে অন্য উদাহরণটি দিয়েছি তা হ'ল সময় নির্ধারণের পক্ষে যুক্তির অনুপ্রেরণা। আমি যে গোষ্ঠীগুলির সাথে কাজ করি তার মধ্যে একটিগুলির সাথে হার্ড রিয়েলটাইমের প্রয়োজনীয়তা সহ কিছু ডিভাইস ড্রাইভার স্টাফ বিকাশ করা প্রয়োজন। তাদের সাথে কাজ করার জন্য 2 টি এপিআই ছিল। একজন ভালো ছিল, একজনও কম ছিল। ভাল এপিআই সময় নির্ধারণ করতে পারেনি কারণ এটি বাস্তবায়নটি আড়াল করে। কম এআইপি বাস্তবায়নটি উন্মোচিত করেছে এবং এর ফলে আপনাকে একটি কার্যকর পণ্য তৈরি করতে প্রসেসর-নির্দিষ্ট কৌশলগুলি ব্যবহার করতে দিন। ভাল এপিআই নম্রভাবে শেল্ফটিতে রাখা হয়েছিল এবং তারা সময়ের প্রয়োজনীয়তাগুলি অব্যাহত রাখে।

— কর্ট অ্যামোন - মনিকা

Answer 6

আপনি অগত্যা জানেন না যে আপনার ডেটার অভ্যন্তরীণ উপস্থাপনা কী - বা ভবিষ্যতে হয়ে উঠতে পারে।

ধরুন আপনার কাছে একটি ডেটা সোর্স রয়েছে যা আপনি অ্যারে হিসাবে উপস্থাপন করছেন, আপনি এটির জন্য নিয়মিত লুপের সাহায্যে পুনরাবৃত্তি করতে পারেন।

এখন বলুন আপনি রিফ্যাক্টর করতে চান। আপনার বস জিজ্ঞাসা করেছেন যে ডেটাসোর্স একটি ডাটাবেস অবজেক্ট হতে পারে। তদুপরি তাঁর কাছে কোনও এপিআই, বা একটি হ্যাশম্যাপ, বা একটি লিঙ্কযুক্ত তালিকা, বা একটি স্পিনিং চৌম্বকীয় ড্রাম, বা একটি মাইক্রোফোন, বা আউট মঙ্গোলিয়ায় পাওয়া ইয়াক শেভিংয়ের রিয়েলটাইম কাউন্ট থেকে ডেটা টানানোর বিকল্প থাকতে হবে।

ঠিক আছে যদি আপনার কাছে লুপের জন্য কেবল একটি থাকে আপনি ডেটা অবজেক্টটি যেভাবে অ্যাক্সেস করবেন বলে আশা করে তাতে সহজেই আপনার কোডটি পরিবর্তন করতে পারেন।

আপনার যদি 1000 ক্লাসে ডেটা অবজেক্টটি অ্যাক্সেস করার চেষ্টা করছে তবে ভাল এখন আপনার একটি বড় রিফ্যাক্টরিং সমস্যা।

একটি পুনরাবৃত্তি একটি তালিকা ভিত্তিক ডেটাসোর্স অ্যাক্সেস করার একটি মানক উপায়। এটি একটি সাধারণ ইন্টারফেস। এটি ব্যবহার করা আপনার কোডটি ডেটাসোর্স অগ্নোস্টিক করে তুলবে।