ধরে নিই যে আপনি কোনও উপহাসের কাঠামোটি খুঁজছেন না, কারণ তারা অতি-সর্বব্যাপী এবং সহজেই খুঁজে পাওয়া যায় , সামনে লক্ষ্য করার মতো কয়েকটি জিনিস রয়েছে:
- আপনার "সর্বদা" করা উচিত "কখনই" কিছু নেই।
তৃতীয় পক্ষের লাইব্রেরিটি গুছিয়ে রাখা সর্বদা সেরা নয়। যদি আপনার অ্যাপ্লিকেশনটি অভ্যন্তরীণভাবে কোনও লাইব্রেরির উপর নির্ভরশীল, বা এটি আক্ষরিক অর্থে এক বা দুটি মূল লাইব্রেরির চারপাশে নির্মিত হয়, তবে এটিকে মোড়ানো আপনার সময় নষ্ট করবেন না। যদি গ্রন্থাগারগুলি পরিবর্তন হয় তবে আপনার অ্যাপ্লিকেশনটির যে কোনও উপায়ে পরিবর্তন করা দরকার ।
- ইন্টিগ্রেশন টেস্ট ব্যবহার করা ঠিক আছে।
এটি বিশেষত এমন সীমানার চারপাশে সত্য যা স্থিতিশীল, আপনার প্রয়োগের অভ্যন্তরীণ বা সহজেই উপহাস করা যায় না। সেই শর্ত পূরণ হয়, মোড়ানো এবং বিদ্রূপকারী হবে জটিল এবং ক্লান্তিকর হবে না। সেক্ষেত্রে, আমি উভয়কে এড়িয়ে চলব: জড়ো করবেন না এবং উপহাস করবেন না; শুধু ইন্টিগ্রেশন পরীক্ষা লিখুন। (যদি স্বয়ংক্রিয় পরীক্ষার লক্ষ্য হয়))
- সরঞ্জাম এবং কাঠামো যৌক্তিক জটিলতা দূর করতে পারে না।
নীতিগতভাবে, একটি সরঞ্জাম কেবল বয়লারপ্লেটে কাটা যেতে পারে। তবে, একটি জটিল ইন্টারফেস গ্রহণ এবং এটিকে সহজ করে তোলার জন্য কোনও স্বয়ংক্রিয়-সক্ষম অ্যালগরিদম নেই - আপনার প্রয়োজন অনুসারে ইন্টারফেস এক্স নিতে এবং এটি খাপ খাইয়ে দিন । (কেবলমাত্র আপনি সেই অ্যালগরিদম জানেন !) সুতরাং, নিঃসন্দেহে এমন কিছু সরঞ্জাম রয়েছে যা পাতলা মোড়ক তৈরি করতে পারে , আমি পরামর্শ দিচ্ছি যে তারা ইতিমধ্যে সর্বব্যাপী নয় কারণ শেষ পর্যন্ত, আপনাকে এখনও বুদ্ধিমানভাবে কোড প্রয়োজন, এবং সুতরাং ম্যানুয়ালি, ইন্টারফেসের বিপরীতে এমনকি এটি কোনও মোড়কের আড়ালে লুকিয়ে রয়েছে।
এটি বলেছিল যে কোনও ক্লাসে সরাসরি উল্লেখ এড়াতে আপনি বিভিন্ন ভাষায় কৌশল অবলম্বন করতে পারেন। এবং কিছু ক্ষেত্রে, আপনি একটি ইন্টারফেস বা পাতলা মোড়কের "উপস্থিত" করতে পারেন যা বাস্তবে বিদ্যমান নেই। সি # তে, উদাহরণস্বরূপ, আমি দুটি রুটের একটিতে যাব:
- একটি কারখানা এবং অন্তর্নিহিত টাইপিং ব্যবহার করুন ।
আপনি এই ছোট কম্বো দিয়ে কোনও জটিল ক্লাসকে পুরোপুরি মোড়ানোর প্রচেষ্টা এড়াতে পারবেন:
// "factory"
class PdfDocumentFactory {
public static ExternalPDFLibraryDocument Build() {
return new ExternalPDFLibraryDocument();
}
}
// code that uses the factory.
class CoreBusinessEntity {
public void DoImportantThings() {
var doc = PdfDocumentFactory.Build();
// ... i have no idea what your lib does, so, I'm making stuff but.
// but, you can do whatever you want here without explicitly
// referring to the library's actual types.
doc.addHeader("Wee");
doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return doc.exportBinaryStreamOrSomething();
}
}
যদি আপনি এই বিষয়গুলিকে সদস্য হিসাবে সংরক্ষণ করতে পারেন, হয় আরও "কার্যকরী" পদ্ধতির মাধ্যমে বা একটি অভিধানে (বা যে কোনও কিছু ) সংরক্ষণ করে , এই মূল পদ্ধতির সাথে আপনার মূল ব্যবসায়িক সংস্থাগুলি সঠিকভাবে জানা দরকার না করে সংকলন-সময়ের ধরণের পরীক্ষার সুবিধা রয়েছে তারা কোন শ্রেণীর সাথে কাজ করছে?
যা প্রয়োজন তা হ'ল সংকলনের সময়, আপনার কারখানায় ফিরে আসা ক্লাসটির আসলে সেই পদ্ধতি রয়েছে যা আপনার ব্যবসায়িক অবজেক্ট ব্যবহার করছে।
- গতিশীল টাইপিং ব্যবহার করুন ।
এটি অন্তর্নিহিত টাইপিংয়ের মতো একই শিরাতে , তবে অন্য ট্রেড অফের সাথে জড়িত: আপনি কম্পাইল-টাইপ চেকগুলি হারাবেন এবং বেনামে শ্রেণীর সদস্য হিসাবে বহিরাগত নির্ভরতা যুক্ত করার এবং আপনার নির্ভরতা ইনজেকশনের ক্ষমতা অর্জন করুন ।
class CoreBusinessEntity {
dynamic Doc;
public void InjectDoc(dynamic Doc) {
Doc = doc;
}
public void DoImortantThings() {
Doc.addHeader("Wee");
Doc.getAllText().makeBiggerBy(4).makeBold().makeItalic();
return Doc.exportBinaryStreamOrSomething();
}
}
এই কৌশল উভয় সঙ্গে, যখন এটি উপহাস সময় আসে ExternalPDFLibraryDocument, আমি তার আগে বলেন, আপনি কি কিছু কাজ আছে - কিন্তু, এটা এর কাজ আপনাকে যা করতে হবে চাই যাহাই হউক না কেন । এবং, এই নির্মাণের সাহায্যে, আপনি ক্লান্তিকরভাবে 100 টি পাতলা ছোট মোড়কের ক্লাসগুলি সংজ্ঞায়িত করে এড়িয়ে গেছেন। আপনি কেবল থাকেন ব্যবহৃত - এটা সরাসরি খুঁজছেন ছাড়া গ্রন্থাগার অধিকাংশ অংশ জন্য।
এই সমস্ত বলেছে, তিনটি বড় কারণ রয়েছে যা আমি এখনও স্পষ্টভাবে একটি তৃতীয় পক্ষের লাইব্রেরি মোড়ক বিবেচনা করব - যার কোনটিই কোনও সরঞ্জাম বা কাঠামো ব্যবহার করার ইঙ্গিত দেবে না:
- নির্দিষ্ট গ্রন্থাগারটি অ্যাপ্লিকেশনটির অভ্যন্তরীণ নয় ।
- এটিকে গুটিয়ে না রেখে অদলবদল করা খুব ব্যয়বহুল হবে।
- আমি নিজেই এপিআই পছন্দ করি না।
এই তিনটি ক্ষেত্রেই যদি আমার কিছু স্তরের উদ্বেগ না থাকে তবে আপনি এটিকে মোড়ানোর জন্য কোনও উল্লেখযোগ্য প্রচেষ্টা করবেন না । এবং, যদি তিনটি ক্ষেত্রেই আপনার কিছু উদ্বেগ থাকে তবে একটি স্বয়ংক্রিয়ভাবে উত্পাদিত পাতলা মোড়ক আসলেই সহায়তা করে না।
আপনি যদি কোনও লাইব্রেরি গুটিয়ে রাখার সিদ্ধান্ত নিয়েছেন তবে আপনার সময়ের সবচেয়ে কার্যকর এবং কার্যকর ব্যবহার হ'ল ইন্টারফেসের বিরুদ্ধে আপনার অ্যাপ্লিকেশনটি তৈরি করা যা আপনি চান ; কোনও বিদ্যমান এপিআইয়ের বিরুদ্ধে নয়।
ক্লাসিকাল উপদেশটি মনোযোগ দিন: আপনি যা করতে পারেন তার প্রতিটি সিদ্ধান্ত স্থগিত করুন। প্রথমে আপনার আবেদনের "কোর" তৈরি করুন। ইন্টারফেসের বিরুদ্ধে কোড যা শেষ পর্যন্ত আপনি যা করতে চান তা করবে, যা শেষ পর্যন্ত "পেরিফেরিয়াল স্টাফ" দ্বারা পরিপূর্ণ হবে যা এখনও বিদ্যমান নেই। প্রয়োজনীয় ফাঁকগুলি ব্রিজ করুন।
এই প্রচেষ্টাটি সময়-সাশ্রয়ের মতো মনে হতে পারে না ; তবে আপনি যদি মনে করেন আপনার একটি মোড়কের দরকার হয় তবে এটি নিরাপদে এটি করার সবচেয়ে কার্যকর উপায় ।
এই ভাবে চিন্তা করুন।
আপনার কোডের কিছু অন্ধকার কোণে আপনাকে এই লাইব্রেরির বিরুদ্ধে কোডিং করতে হবে - এমনকি এটি মোড়ানো হলেও। আপনি যদি পরীক্ষার সময় গ্রন্থাগারটিকে উপহাস করেন তবে সেখানে অপ্রয়োজনীয় ম্যানুয়াল প্রচেষ্টা রয়েছে - এমনকি এটি মোড়ানো থাকলেও। তবে, এর অর্থ এই নয় যে আপনার অ্যাপ্লিকেশনটির বেশিরভাগ অংশে আপনাকে সরাসরি সেই লাইব্রেরিটি নাম দিয়ে স্বীকৃতি দেওয়া দরকার ।
TLDR
লাইব্রেরিটি মোড়ানোর উপযোগী হলে আপনার তৃতীয় পক্ষের লাইব্রেরিতে সরাসরি, সরাসরি উল্লেখগুলি এড়াতে কৌশলগুলি ব্যবহার করুন তবে পাতলা মোড়ক তৈরি করার জন্য শর্টকাট নেবেন না। প্রথমে আপনার ব্যবসায়ের যুক্তি তৈরি করুন, আপনার ইন্টারফেসগুলি সম্পর্কে ইচ্ছাকৃত করুন এবং প্রয়োজন অনুসারে আপনার অ্যাডাপ্টারগুলি জৈবিকভাবে উত্থিত করুন ।
এবং, যদি এটি আসে তবে ইন্টিগ্রেশন পরীক্ষায় ভয় পাবেন না। এগুলি কিছুটা অদ্ভুত, তবে তারা এখনও ওয়ার্কিং কোডের প্রমাণ দেয় এবং তাদের এখনও সহজেই উপসাগরীয় স্থানে রাখা যায়।