বিমূর্ততা উপর নির্ভর করে কোন উল্লেখযোগ্য অসুবিধা আছে?

Question

আমি এই উইকিটি স্ট্যাবল অ্যাবস্ট্রাকশন প্রিন্সিপালে (এসএপি) পড়ছিলাম ।

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

Comments

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

— কিলিয়ান ফট

আপনি কি লিঙ্কযুক্ত নিবন্ধ এবং / অথবা নিবন্ধটি ভিত্তিক বইটি পড়েছেন ?

— জার্গ ডব্লু মিট্টাগ

+1 ভাল প্রশ্ন, বিশেষত যেহেতু আমি স্থিতি এবং বিমূর্ততার মধ্যে সম্পর্ক তত্ক্ষণাত স্বজ্ঞাত মনে করি না। এই নিবন্ধটির পৃষ্ঠা 11 সহায়তা করে, বিমূর্ত মামলার উদাহরণটি এর অর্থটি তোলে, তবে সম্ভবত কেউ কংক্রিটের ক্ষেত্রে আরও পরিষ্কার উদাহরণ লিখতে পারেন। ধরে রাখার অনুরোধ

— মাইক

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

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

— স্টিভক্যালেন্ডার

Answer 1

আপনার প্যাকেজগুলিকে একটি এপিআই হিসাবে ভাবুন, কাগজ থেকে উদাহরণটি নিতে, আপনার বিমূর্ত API এর Readerসাথে string Reader.Read()এবং Writerসাথে সংজ্ঞা গ্রহণ করুন void Writer.Write(string)।

তারপরে আপনি Copyকোনও পদ্ধতি Copier.Copy(Reader, Writer)এবং বাস্তবায়ন Writer.Write(Reader.Read())এবং সম্ভবত কিছু বিচক্ষণতার পরীক্ষা দিয়ে একটি শ্রেণি তৈরি করতে পারেন ।

এখন, আপনি কংক্রিট বাস্তবায়নের করতে, যেমন FileReader, FileWriter, KeyboardReaderএবং DownloadThingsFromTheInternetReader।

আপনি যদি নিজের প্রয়োগ পরিবর্তন করতে চান FileReader? কোনও সমস্যা নেই, কেবল ক্লাস পরিবর্তন করুন এবং পুনরায় কম্পাইল করুন।

আপনি যদি নিজের বিমূর্ততার সংজ্ঞা পরিবর্তন করতে চান তবে কী হবে Reader? ওহো, আপনি ঠিক যে পরিবর্তন করতে পারবেন না, কিন্তু আপনি পরিবর্তন করতে হবে Copier, FileReader, KeyboardReaderএবং DownloadThingsFromTheInternetReader।

এটি স্থিতিশীল বিমূর্তন নীতির পিছনে যুক্তি: আপনার কনট্রেটিসেশনগুলি বিমূর্তির তুলনায় কম স্থিতিশীল করুন Make

Comments

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

— স্টিভক্যালেন্ডার

@ স্টিভালেকেন্ডার এটি সূক্ষ্ম পার্থক্য: "স্থায়িত্ব" এর লেখকের সংজ্ঞাটি বেশিরভাগ লোককে "স্থিতিশীলতার প্রয়োজন" বলে সম্বোধন করে।

— Residuum

Answer 2

ইয়াগনির কারণে ।

আপনার যদি বর্তমানে কেবলমাত্র একটি জিনিসের বাস্তবায়ন হয় তবে অতিরিক্ত এবং অকেজো স্তর দিয়ে বিরক্ত করছেন কেন? এটি কেবল অপ্রয়োজনীয় জটিলতার দিকে পরিচালিত করবে। আরও খারাপ, কখনও কখনও আপনি দ্বিতীয় প্রয়োগ বাস্তবায়নের দিনটি আসার জন্য একটি বিমূর্ত চিন্তাভাবনা সরবরাহ করেন ... এবং এই দিনটি কখনই ঘটে না। কী কাজের অপচয়!

আমি আরও মনে করি যে নিজেকে জিজ্ঞাসা করার আসল প্রশ্নটি "আমার কি বিমূর্তির উপর নির্ভর করতে হবে?" তবে বরং "আমার কি মডুলারালিটি দরকার?"। এবং সর্বদা মডুলারিটির প্রয়োজন হয় না, নীচে দেখুন।

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

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

Comments

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

— ফুহরম্যানেটর

@ ফুহরম্যানেটর সাধারণ কোড বিমূর্ততা থেকে পৃথক। প্রচলিত কোডটি কেবল একটি সহায়ক পদ্ধতি বা গ্রন্থাগারকে বোঝাতে পারে - কোনও বিমূর্ততা প্রয়োজন হয় না।

— আইলন

@ ফুহরম্যানেটর অবশ্যই আমাদের লাইব্রেরিতে প্রচলিত কোড রয়েছে তবে আইলন যেমন বলেছিলেন, সবকিছু বিমূর্তির উপর নির্ভর করে না (কিছু অংশ অবশ্য আছে)। আমি কখনই বলিনি যে কোনওদিনও বাগ নেই, আমি বলেছিলাম যে তাদের প্যাচ করা যাবে না (যে কারণে ওপির প্রশ্নের ক্ষেত্রের বাইরে)।

— 11:15

@ ইলন আমার মন্তব্য সম্পর্কে মডিউলারিটি সম্পর্কে সর্বদা প্রয়োজন হয় না (বিমূর্ততা নয়)।

— ফুহরম্যানেটর

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

— ফুহরম্যানেটর

Answer 3

আমি মনে করি আপনি সম্ভবত রবার্ট মার্টিন দ্বারা নির্বাচিত স্থির শব্দটি দ্বারা বিভ্রান্ত হয়ে পড়েছেন। এখানে আমি মনে করি যে বিভ্রান্তি শুরু হয়:

এটি সূচিত করে যে কোনও প্যাকেজ যদি কম স্থিতিশীল হয় (পরিবর্তনের সম্ভাবনা বেশি থাকে) তবে এটি আরও কংক্রিট হওয়া উচিত।

আপনি যদি মূল নিবন্ধটি পড়ে থাকেন তবে আপনি (জোর দেওয়া খনি) দেখতে পাবেন:

স্থায়িত্ব শব্দের ক্লাসিক সংজ্ঞাটি হ'ল: "সহজেই সরানো হয় না।" এই সংজ্ঞাটি আমরা এই নিবন্ধটিতে ব্যবহার করব। যে, স্থায়িত্ব একটি মডিউল পরিবর্তিত হবে সম্ভাবনা একটি পরিমাপ নয়; বরং এটি একটি মডিউল পরিবর্তন করতে অসুবিধা একটি পরিমাপ ।

স্পষ্টতই, মডিউলগুলি যেগুলি পরিবর্তন করা আরও কঠিন, কম অস্থির হতে চলেছে। মডিউলটি যত শক্ত হয় ততই স্থির হয়, তত বেশি স্থিতিশীল হয়।

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

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

সুতরাং, "দায়বদ্ধ" এর চেতনার অনুসরণ করে আমি পরিবর্তন করতে অসুবিধার জন্য বিকল্প অর্থ নিয়ে এসেছি (বা পরিবর্তন হওয়া উচিত নয় ):

• দায়বদ্ধ - অর্থ অন্যান্য শ্রেণি এই শ্রেণীর উপর নির্ভর করে তাই এটি পরিবর্তন করা উচিত নয় ।
• হেইনেন - আইবিড
• সীমাবদ্ধ - এই শ্রেণীর বাধ্যবাধকতা পরিবর্তনে এর সুবিধা সীমাবদ্ধ করে।

সুতরাং, বিবৃতিতে এই সংজ্ঞাগুলি প্লাগ করুন

একটি প্যাকেজ যত স্থির হয় তত বিমূর্ত হওয়া উচিত

• একটি প্যাকেজ যত বেশি বাধ্যতামূলক তত বিমূর্ত হওয়া উচিত ract
• আরো বাধিত একটি প্যাকেজ বিমূর্ত এটি হওয়া উচিত
• একটি প্যাকেজ যতই বাধা দেয় তত বিমূর্ত হওয়া উচিত

বিভ্রান্তিকর শব্দের স্থিতিশীল / অস্থিরতার উপর জোর দিয়ে স্থিতিশীল বিমূর্তি নীতি (এসএপি) এর উদ্ধৃতি দেওয়া যাক:

সর্বাধিক স্থিতিশীল প্যাকেজগুলি সর্বাধিক বিমূর্ত হওয়া উচিত। অস্থির প্যাকেজগুলি কংক্রিট হওয়া উচিত। প্যাকেজের বিমূর্ততা তার স্থায়িত্বের অনুপাতে হওয়া উচিত ।

এই বিভ্রান্তিকর শব্দ ছাড়া এটি স্পষ্ট করা:

প্যাকেজগুলি যা সিস্টেমের অন্যান্য অংশে সর্বাধিক দেখা হয় সেগুলি সর্বাধিক বিমূর্ত হওয়া উচিত। যে প্যাকেজগুলি অসুবিধা ছাড়াই পরিবর্তন করতে পারে সেগুলি কংক্রিট হওয়া উচিত। কোনও প্যাকেজের বিমূর্ততা সংশোধন করা কতটা কঠিন হবে তার অনুপাতে হওয়া উচিত ।

টি এল; ডিআর

আপনার প্রশ্নের শিরোনাম জিজ্ঞাসা করে:

বিমূর্ততা উপর নির্ভর করে কোন উল্লেখযোগ্য অসুবিধা আছে?

আমি মনে করি আপনি যদি বিমূর্তিগুলি সঠিকভাবে তৈরি করেন (যেমন, তাদের প্রচুর কোড নির্ভর করে কারণ এগুলি বিদ্যমান) তবে কোনও উল্লেখযোগ্য অসুবিধা নেই।

Answer 4

এটি সূচিত করে যে কোনও প্যাকেজ যদি কম স্থিতিশীল হয় (পরিবর্তনের সম্ভাবনা বেশি থাকে) তবে এটি আরও কংক্রিট হওয়া উচিত। যা আমি সত্যিই বুঝতে পারি না কেন এটি হওয়া উচিত।

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

সুতরাং, যদি আপনার প্যাকেজটি প্রায়শই পরিবর্তিত হতে থাকে, তবে এটি ভাল বিমূর্ততা নয়, কনক্রিটগুলি সরবরাহ করা উচিত। নাহলে ... কে এটা ব্যবহার করবে? ;)

Answer 5

মার্টিনের স্থায়িত্ব মেট্রিক এবং "স্থিতিশীলতা" দ্বারা তার অর্থ কী তা মনে রাখবেন:

Instability = Ce / (Ca+Ce)

বা:

Instability = Outgoing / (Incoming+Outgoing)

অর্থাৎ, কোনও প্যাকেজ সম্পূর্ণরূপে অস্থির হিসাবে বিবেচিত হয় যদি এর সমস্ত নির্ভরতা বাইরে চলে যায়: এটি অন্যান্য জিনিস ব্যবহার করে, তবে কিছুই এটি ব্যবহার করে না। সেক্ষেত্রে এটি কেবল সেই জিনিসটিকেই কংক্রিটের পক্ষে বোঝা যায়। এটি পরিবর্তন করার সহজতম ধরণের কোড হতে চলেছে যেহেতু অন্য কোনও কিছুই এটি ব্যবহার করে না, এবং সেইজন্য কোডটি সংশোধন করা হলে অন্য কোনও কিছুই ভঙ্গ করতে পারে না।

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

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

বিমূর্ততা উপর নির্ভর করে কোন উল্লেখযোগ্য অসুবিধা আছে?

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

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

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