একটি একক কনফিগার অবজেক্টটি কী খারাপ ধারণা?


43

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

একটি সমস্যা হ'ল আপনি সাধারণত যে কনফিগারেশনটি চালান তার সাথে পরীক্ষা করতে চান না। এর বেশ কয়েকটি সমাধান রয়েছে:

  • কনফিগার অবজেক্টটিকে এমন একটি সেটার দিন যা কেবলমাত্র পরীক্ষার জন্য ব্যবহৃত হয়, যাতে আপনি বিভিন্ন সেটিংসে পাস করতে পারেন।
  • একটি একক কনফিগার অবজেক্ট ব্যবহার করা চালিয়ে যান, তবে এটি একটি সিঙ্গলটন থেকে এমন এক পরিস্থিতিতে পরিবর্তন করুন যা আপনি যেদিকেই প্রয়োজন সেখানে ঘুরে যান। তারপরে আপনি এটিকে একবার আপনার অ্যাপ্লিকেশনটিতে এবং একবার একবার পরীক্ষা করে বিভিন্ন সেটিংসের সাহায্যে তৈরি করতে পারেন।

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

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


কনফিগারেশনটি ডিস্কে একটি ফাইল পড়ে তার সেটিংস পায়, তাই না? তাহলে কেন কেবল এটি "টেস্টকনফিগ" ফাইলটি পড়তে পারে না?
আনন

এটি প্রথম সমস্যার সমাধান করে তবে দ্বিতীয়টি নয়।
JW01

@ জেডব্লিউ 01: আপনার সমস্ত পরীক্ষার কি খুব আলাদা কনফিগারেশন দরকার? আপনার পরীক্ষা চলাকালীন কোথাও সেই কনফিগারেশনটি সেটআপ করতে হবে , তাই না?
আনন

সত্য। তবে যদি আমি সেটিংসের একক পুল (পরীক্ষার জন্য আলাদা পুল সহ) ব্যবহার চালিয়ে যাই তবে আমার সমস্ত পরীক্ষাগুলি একই সেটিংস ব্যবহার করে শেষ হয়। এবং যেহেতু আমি আচরণটি বিভিন্ন সেটিংসের মাধ্যমে পরীক্ষা করতে চাইতে পারি, এটি আদর্শ নয়।
JW01

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

উত্তর:


35

আমার একটি একক কনফিগার অবজেক্টে সমস্যা নেই এবং সমস্ত সেটিংসকে এক জায়গায় রাখার সুবিধাটি দেখতে পাচ্ছি।

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

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

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


7

আমি ইন্টারফেসের সাথে সম্পর্কিত সেটিংসের গোষ্ঠীগুলিকে আলাদা করি।

কিছুটা এইরকম:

public interface INotificationEmailSettings {
   public string To { get; set; }
}

public interface IMediaFileSettings {
    public string BasePath { get; set; }
}

প্রভৃতি

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

তবে ইন্টারফেসের মাধ্যমে পৃথকীকরণ প্রকৃত নির্ভরতা অনেক বেশি সুস্পষ্ট এবং সূক্ষ্ম দানাযুক্ত করে তোলে এবং এটি পরীক্ষার জন্য সুস্পষ্ট উন্নতি।

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

সুতরাং, আমি স্টেকড ক্লাসটি ফেকড হিসাবে ব্যবহার করব, যে কোনও জায়গা থেকে সেটিংসে সহজ প্রবেশাধিকার সরবরাহ করব এবং সেই স্ট্যাটিক ক্লাসের মধ্যে আমি ইন্টারফেসের বাস্তবায়ন সনাক্ত করতে এবং সেটিংসটি পেয়ে যাব।

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

public static class AllSettings {
    public INotificationEmailSettings NotificationEmailSettings {
        get {
            return ServiceLocator.Get<INotificationEmailSettings>();
        }
    }
}

আমি এই মিশ্রণটিকে সমস্ত বিশ্বের সেরা বলে মনে করি।


3

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

(বাধ্যতামূলক রেফারেন্স: লিগ্যাসি কোডের সাথে কার্যকরভাবে কাজ করা It এতে ইউনিট পরীক্ষার উত্তরাধিকার কোডের জন্য এটি এবং আরও অনেক অমূল্য কৌশল রয়েছে))

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

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


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

1
@ কেআরন, লিগ্যাসি কোড ইউনিটকে টেস্টযোগ্য করে তোলার জন্য এগুলি প্রচুর উপকারী এবং ব্যবহারিক কৌশল এবং আমি এগুলি আরও ব্যাপকভাবে ব্যবহার করছি। তবে, আদর্শভাবে উত্পাদন কোডটিতে কেবলমাত্র পরীক্ষার উদ্দেশ্যে প্রবর্তিত কোনও বৈশিষ্ট্য থাকা উচিত নয়। দীর্ঘমেয়াদে, আমি এদিকেই প্রত্যাবর্তন করছি।
প্যাটার তুরিক

2

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

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


2

এই প্রশ্নটি কনফিগারেশনের চেয়ে আরও সাধারণ সমস্যা সম্পর্কে। "সিঙ্গেলটন" শব্দটি পড়ার সাথে সাথে আমি তত্ক্ষণাত্ সেই প্যাটার্নটির সাথে সম্পর্কিত সমস্ত সমস্যা নিয়ে ভাবলাম, যার মধ্যে কমপক্ষে টেস্টাবিলিটিও নয়।

সিঙ্গলটন প্যাটার্নটি "ক্ষতিকারক হিসাবে বিবেচিত"। অর্থ, এটি সর্বদা ভুল জিনিস নয়, তবে এটি সাধারণত হয়। আপনি যদি কখনও কোনও কিছুর জন্য সিঙ্গলটন প্যাটার্ন ব্যবহার করার বিষয়ে বিবেচনা করেন তবে বিবেচনা বন্ধ করুন:

  • আপনি কি কখনও এটি সাবক্লাস প্রয়োজন?
  • আপনি কি কখনও একটি ইন্টারফেস প্রোগ্রাম করতে হবে?
  • আপনার বিরুদ্ধে ইউনিট পরীক্ষা চালানো দরকার?
  • আপনার কি এটি ঘন ঘন সংশোধন করা দরকার?
  • আপনার অ্যাপ্লিকেশনটি কি একাধিক উত্পাদন প্ল্যাটফর্ম / পরিবেশ সমর্থন করার উদ্দেশ্যে তৈরি?
  • আপনি কি মেমরি ব্যবহার সম্পর্কে কিছুটা উদ্বিগ্ন?

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

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


0

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

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

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


0

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

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

অবশেষে, এমন একটি বিশ্বব্যাপী রাষ্ট্র তৈরি করা এনক্যাপসুলেশন লঙ্ঘন কারণ আপনি সরাসরি ডেটা অ্যাক্সেস করার প্রয়োজনের চেয়ে বেশি ক্লাসকে মঞ্জুরি দিচ্ছেন।


0

আমি মনে করি যে যদি সম্পর্কিতগুলিগুলির "ক্লাম্পগুলি" সহ অনেকগুলি সেটিংস থাকে তবে সেগুলি স্বতন্ত্র বাস্তবায়নের সাথে পৃথক ইন্টারফেসে ভাগ করে নেওয়া বুদ্ধিমান হয়ে যায় - তারপরে ডিআইয়ের সাথে যেখানে প্রয়োজন সেখানে সেই ইন্টারফেসগুলি ইনজেক্ট করুন। আপনি পরীক্ষারযোগ্যতা, কম সংযোগ এবং এসআরপি অর্জন করুন।

আমি লস টেকিজের জোশুয়া ফ্লানাগান দ্বারা এই বিষয়ে অনুপ্রেরণা পেয়েছি; কিছুক্ষণ আগে তিনি এই বিষয়ে একটি নিবন্ধ লিখেছিলেন

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.