আপনি কতটা কঠোরভাবে "কোনও নির্ভরতা চক্র নয়" নিয়মটি অনুসরণ করেন (এনডিপেন্ডেড)

Question

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

পরিষ্কার হতে হবে: "নির্ভরতা চক্র" এর অধীনে আমি দুটি নেমস্পেসের মধ্যে একটি বিজ্ঞপ্তি উল্লেখ বুঝতে পারি।

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

• কোর নেভিগেশন এবং মেনু সাবসিস্টেম
• স্ক্রিন সাবসিস্টেম (উপস্থাপক / দর্শন / ...)
• নিয়ন্ত্রণ / উইজেট স্তর

আজ আমি অর্ধেক দিনটি কোডটি যথাযথ স্তরে আনার চেষ্টা করার জন্য ব্যয় করেছি [রেশার্পারকে ধন্যবাদ সাধারণভাবে কোনও সমস্যা নেই] তবে সমস্ত ক্ষেত্রে কিছুটা নির্ভরশীলতা চক্র বিদ্যমান exist

সুতরাং আমার প্রশ্ন: আপনি "কোনও নির্ভরতা চক্র" নিয়মটি কত কঠোরভাবে অনুসরণ করেন? স্তরায়ন কি আসলেই গুরুত্বপূর্ণ?

Comments

যদি "কোনও নির্ভরতা চক্র নয়" এর অর্থ কোনও বিজ্ঞপ্তি উল্লেখ নেই, তবে - কোনও অজুহাত নয়। এগুলি খাঁটি মন্দ।

— অ্যারিস ল্যাপসা

@ ওলিফ্যান্ট: আপনি যখন "নো ডিপেন্ডেন্সি সাইকেল" লেখেন তখন আপনার অর্থটি কী তা বোঝান। স্তরগুলির মধ্যে বা একটি স্তরের মধ্যে শ্রেণিগুলির মধ্যে?

— ডক ব্রাউন

Answer 1

আমি সম্প্রতি 2 টি সাদা বই লিখেছি, যা আর্কিটেকচারের বিষয়টি নিয়ে সিম্পল-টক-এ প্রকাশিত। নেট কোড (প্রথম বইটি। নেট সংস্থাগুলি, নেমস্পেস এবং লেভেলাইজেশন সম্পর্কে দ্বিতীয়):

.NET সমাবেশ এবং ভিজ্যুয়াল স্টুডিও প্রকল্পগুলির মাধ্যমে আপনার কোড বেস ভাগ করা Base

নেমস্পেসের সাথে নেট নেটওয়ার্কের সংজ্ঞা দেওয়া হচ্ছে

স্তরায়ন কি আসলেই গুরুত্বপূর্ণ?

হ্যাঁ!

২ য় সাদা বইয়ের উদ্ধৃতি:

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

(...)

যতক্ষণ না অ্যাসাইক্লিক উপাদানগুলির সীমাবদ্ধতা অব্যাহতভাবে শ্রদ্ধা করা হয় ততক্ষণ কোড বেসটি অত্যন্ত শেখা এবং বজায় রাখা যায় remains

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

Answer 2

আমি কখনই ক্লাস বা নেমস্পেসের মধ্যে বিজ্ঞপ্তি নির্ভরতা রাখি না। সি #, জাভা এবং সি ++ এ আপনি সর্বদা একটি ইন্টারফেস প্রবর্তন করে একটি বৃত্তাকার শ্রেণি নির্ভরতা ভেঙে ফেলতে পারেন।

পরীক্ষার প্রথম কোডিংয়ের ফলে বিজ্ঞপ্তি নির্ভরতা প্রবর্তন করা কঠিন হয়ে পড়ে।

Answer 3

এটি সর্বদা একটি বাণিজ্য: নির্ভরতা কেন এড়ানো হবে তা বুঝতে আপনাকে নির্ভরতার মূল্য বুঝতে হবে understand একইভাবে, আপনি যদি নির্ভরতার ব্যয়টি বুঝতে পারেন তবে এটি আপনার নির্দিষ্ট ক্ষেত্রে উপযুক্ত কিনা তা আপনি আরও ভাল করে সিদ্ধান্ত নিতে পারেন।

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

আপনার সফ্টওয়্যারটি যদি জাদুকরীতে চালাতে হয় (হার্ডওয়্যার, ওএস, বা কেবল ডিজাইন হিসাবে ("সহজ ইউআইআই আমরা পারি") এর মত) যদি আপনি ডাইনিতে সীমাবদ্ধতাগুলি বুঝতে পারেন তবে বুঝতে হবে যে নির্ভরতাগুলি করা উচিত নয় এবং এটি কোনটি নয় ঠিক আছে.

তবে আপনার যদি ভাল এবং স্পষ্ট কারণ না থাকে তবে আপনি যে কোনও নির্ভরতা এড়াতে পারবেন না। নির্ভরশীল কোডটি ডিবাগ-সেশনের নরক।

Answer 4

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

এটি বলেছিল, জন লাকোস সমস্ত (বিল্ড-টাইম) চক্রটি নির্মূল করার বিষয়ে অত্যন্ত কঠোর ছিলেন। তবে বব মার্টিন এমন দৃষ্টিভঙ্গি গ্রহণ করেছিলেন যে কেবল বাইনারিগুলির মধ্যে চক্রগুলি (যেমন ডিএলএল, এক্সিকিউটেবল) গুরুত্বপূর্ণ ছিল এবং এড়ানো উচিত; তিনি বিশ্বাস করেছিলেন যে বাইনারি মধ্যে ক্লাসের মধ্যে চক্র মারাত্মক গুরুত্বপূর্ণ নয়।

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

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

Answer 5

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