অবজেক্ট ওরিয়েন্টেড ডিজাইনে লুজ কাপলিং

Question

আমি জিআরএসপি শিখতে চেষ্টা করছি এবং লো কাপলিংয়ের সম্পর্কে এটি ব্যাখ্যা করা ( 3 পৃষ্ঠায় এখানে ) পেয়েছি এবং এটি পেয়ে আমি খুব অবাক হয়েছিলাম:

শ্রেণীর addTrackজন্য পদ্ধতিটি বিবেচনা করুন Album, দুটি সম্ভাব্য পদ্ধতি হ'ল:

addTrack( Track t )

এবং

addTrack( int no, String title, double duration )

কোন পদ্ধতিতে মিলন হ্রাস হয়? দ্বিতীয়টি করে, যেহেতু অ্যালবাম ক্লাস ব্যবহার করে ক্লাসটি একটি ট্র্যাক ক্লাস জানতে হবে না। সাধারণভাবে, পদ্ধতিগুলির প্যারামিটারগুলিতে জাভা থেকে বেস টাইপ (ইনট, চর ...) এবং ক্লাস ব্যবহার করা উচিত *

আমি এই সাথে ডায়াগ্রির ঝোঁক; আমি বিশ্বাস করি addTrack(Track t)বেশী ভালো addTrack(int no, String title, double duration)বিভিন্ন কারণে:

1. যতটা সম্ভব কম প্যারামিটার করা কোনও পদ্ধতির পক্ষে সর্বদা ভাল (চাচা বব এর ক্লিন কোড অনুসারে কেউ বা একটিও নয়, কিছু ক্ষেত্রে 2 এবং বিশেষ ক্ষেত্রে 3 টিরও বেশি রিফ্যাক্টরিং প্রয়োজন - এগুলি অবশ্যই সুপারিশগুলি হোল বিধি নয়) ।

2. যদি addTrackকোনও ইন্টারফেসের কোনও পদ্ধতি হয় এবং প্রয়োজনীয়তার প্রয়োজন হয় যে Trackএকটিতে আরও তথ্য থাকা উচিত (বলুন বছর বা জেনার) তবে ইন্টারফেসটি পরিবর্তন করা দরকার এবং যাতে পদ্ধতিটি অন্য প্যারামিটার সমর্থন করে।

3. এনক্যাপসুলেশন ভেঙে গেছে; যদি addTrackকোনও ইন্টারফেসে থাকে, তবে এটির ইন্টারনালগুলি জানা উচিত নয় Track।

4. এটি বেশিরভাগ পরামিতি সহ দ্বিতীয় উপায়ে আরও সংযুক্ত হয়। ধরুন noপ্যারামিটারটি বদলে নেওয়া intদরকার longকারণ MAX_INTট্র্যাকের চেয়ে বেশি রয়েছে (বা যে কোনও কারণেই); তবে Trackপদ্ধতি এবং পদ্ধতি উভয়ই পরিবর্তন করা দরকার যখন পদ্ধতিটি addTrack(Track track)কেবলমাত্র Trackপরিবর্তিত হত।

সমস্ত 4 টি যুক্তি প্রকৃতপক্ষে একে অপরের সাথে সংযুক্ত এবং সেগুলির কিছু অন্যের পরিণতি।

কোন পদ্ধতির ভাল?

Comments

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

— ডেরেক

সত্য, যখনই আমি "সেরা অভ্যাসগুলি" সম্পর্কে পড়ি আমি এগুলিকে নুনের দানা দিয়ে নিয়ে যাই!

— আরাক

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

— m3th0dman

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

— আরাক

@ আরাক নির্ভরযোগ্য এর অর্থ প্রশ্নাতীত নয়; এবং এটি আমি এখানে যা করছি তা নিয়ে প্রশ্ন করছি।

— m3th0dman

Answer 1

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

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

তিনি সিস্টেমের সমস্ত সংযোগকে সামগ্রিক হিসাবে বিবেচনা করতে ব্যর্থ হচ্ছেন। Trackক্লাস প্রবর্তনের সময় স্বীকৃতভাবে দুটি স্বতন্ত্র মডিউলগুলির মধ্যে আরেকটি নির্ভরতা যুক্ত করে, এটি সিস্টেমের মিলনকে উল্লেখযোগ্যভাবে হ্রাস করতে পারে , যা এখানে গুরুত্বপূর্ণ পরিমাপ।

উদাহরণস্বরূপ, একটি "প্লেলিস্টে যুক্ত করুন" বোতাম এবং একটি Playlistবিষয় বিবেচনা করুন। Trackযদি আপনি কেবলমাত্র দুটি দুটি বিষয় বিবেচনা করেন তবে কোনও বস্তুর পরিচয় সংযোগ বাড়ানো বিবেচনা করা যেতে পারে। আপনার এখন দুটি পরিবর্তে তিনটি আন্তঃনির্ভরশীল ক্লাস রয়েছে। তবে এটি আপনার সিস্টেমের সম্পূর্ণতা নয়। আপনার ট্র্যাকটি আমদানি করতে হবে, ট্র্যাকটি খেলতে হবে, ট্র্যাকটি প্রদর্শন করতে হবে ইত্যাদি etc. মিশ্রণে আরও একটি ক্লাস যুক্ত করা নগন্য।

এখন কেবল স্থানীয়ভাবে পরিবর্তে নেটওয়ার্কের মাধ্যমে ট্র্যাক খেলতে সহায়তা যুক্ত করার বিষয়টি বিবেচনা করুন। আপনার কেবল এমন একটি NetworkTrackবিষয় তৈরি করতে হবে যা একই ইন্টারফেসের সাথে সামঞ্জস্য হয়। Trackঅবজেক্টটি না থাকলে আপনাকে সর্বত্র এই জাতীয় ফাংশন তৈরি করতে হবে:

addNetworkTrack(int no, string title, double duration, URL location)

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

আপনার রিপল ইফেক্ট পরীক্ষাটি আপনার মিলনের সত্য পরিমাণ নির্ধারণ করার জন্য একটি ভাল। আমরা যা নিয়ে উদ্বিগ্ন তা স্থান পরিবর্তন সীমাবদ্ধ করে দিচ্ছে।

Comments

+ আদিমদের সাথে মিলিত হওয়া এখনও তা কাটা কাটছে তা নির্ধারণ করেই চলছে।

— জাস্টিনসি

যুক্ত করার জন্য ইউআরএল বিকল্প / রিপল প্রভাব উল্লেখ করার জন্য +1।

— user949300

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

— মার্জন ভেনেমা

মোট সিস্টেম কাপলিং এবং মডিউল কাপলিংয়ের মধ্যে পার্থক্য সম্পর্কে দুর্দান্ত ব্যাখ্যা দেওয়ার কারণে গ্রহণযোগ্য উত্তর।

— m3th0dman

Answer 2

আমার সুপারিশটি হ'ল:

ব্যবহার

addTrack( ITrack t )

তবে নিশ্চিত হন যে ITrackএটি একটি ইন্টারফেস, একটি কংক্রিট শ্রেণি নয়।

অ্যালবাম ITrackপ্রয়োগকারীদের ইন্টার্নালগুলি জানে না । এটি কেবলমাত্র দ্বারা সংজ্ঞায়িত চুক্তিতে মিলিত হয়েছে ITrack।

আমি মনে করি এটিই সমাধান যা কমপক্ষে সংযুক্তির পরিমাণ উত্পন্ন করে।

Comments

আমি বিশ্বাস করি যে ট্র্যাক কেবল একটি সিম / ডেটা স্থানান্তর অবজেক্ট, যেখানে এটির উপর কেবল ক্ষেত্র এবং গেটার / সেটটার রয়েছে; এই ক্ষেত্রে একটি ইন্টারফেস প্রয়োজন?

— m3th0dman

প্রয়োজনীয়? সম্ভবত না. পরামর্শমূলক, হ্যাঁ একটি ট্র্যাকের কংক্রিট অর্থ বিকশিত হতে পারে এবং হতে পারে, তবে গ্রাসকারী শ্রেণি যা থেকে এটি প্রয়োজন তা সম্ভবত তা করবে না।

— জাস্টিনসি

@ m3th0dman সর্বদা বিমূর্তির উপর নির্ভর করে, কোন সিদ্ধান্তে নয়। এটি Trackবোবা বা স্মার্ট হয়ে নির্বিশেষে প্রযোজ্য । Trackএকটি সংক্ষেপণ। ITrackইন্টারফেস একটি বিমূর্ততা। এইভাবে আপনি ভবিষ্যতে বিভিন্ন ধরণের ট্র্যাক রাখতে সক্ষম হবেন যতক্ষণ না তারা তা মেনে চলে ITrack।

— তুলাইনস কর্ডোভা

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

— বেনিয়ামিন ব্রুমফিল্ড

আপনি ঠিক বলেছেন আমি উপসর্গটি পছন্দ করি না, যদিও আমি স্বচ্ছতার জন্য উত্তরে রেখে যাব।

— তুলাইনস কর্ডোভা

Answer 3

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

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

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

Comments

আমি দেখতে পাচ্ছি না যে অন্য ক্লাসে অন্তর্নিহিত রেফারেন্স থাকা সুস্পষ্ট রেফারেন্সের চেয়ে আরও বেশি মিলিত হয়ে যায়। যেভাবেই হোক, দুটি ক্লাস একত্রিত হয়। আমি মনে করি এই সংমিশ্রনের বিষয়টি সুস্পষ্ট হওয়া ভাল, তবে আমি মনে করি না এটি কোনও "আরও" মিলিত হয় either

— TMN

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

— ডেরেক

Answer 4

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

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

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

আপনি যে জায়গাটি ব্যবহার করতে চান না তা Trackহ'ল যদি Trackঅভ্যন্তরীণ যুক্তি থাকে যা আপনি কলারের কাছে অ্যাক্সেস রাখতে চান না। অন্য কথায়, যদি Albumআপনার পাঠাগার ব্যবহার করে এমন কোনও প্রোগ্রামার ব্যবহার করা ক্লাস হত Trackতবে আপনি এটি ব্যবহার করতে চাইলে তাকে এটি ব্যবহার করতে চাইবেন না , এটি ডাটাবেসটিতে চালিয়ে যাওয়ার জন্য কোনও পদ্ধতি কল করুন। এর সাথে আসল সমস্যাটি সত্য যে মিথ্যা ইন্টারফেসটি মডেলের সাথে জড়িত in

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

অবশ্যই এটি একটি উদাহরণ মাত্র is আমি নিশ্চিত যে এটি মোটেও আপনার ঘটনা নয় এবং তাই Trackঅপরাধবোধ মুক্ত ব্যবহারে নির্দ্বিধায় । আপনি যখন ক্লাস তৈরি করছেন তখন আপনার কলারটিকে মনে রাখবেন এবং প্রয়োজনের সময় ইন্টারফেস তৈরি করার বিষয়টি মনে রাখবেন।

Answer 5

দুটোই সঠিক

addTrack( Track t ) 

হয় ভাল (যদি ইতিমধ্যে argumented হিসাবে) যখন

addTrack( int no, String title, double duration ) 

হয় কম মিলিত কারণ কোডটি ব্যবহার addTrackজানার আছে প্রয়োজন হয় না Trackবর্গ। কলিং কোডটি আপডেট করার প্রয়োজন ছাড়াই ট্র্যাকটির নতুন নামকরণ করা যেতে পারে can

আপনি আরও পঠনযোগ্য / রক্ষণাবেক্ষণযোগ্য কোড সম্পর্কে কথা বলার সময় নিবন্ধটি সংযোগের বিষয়ে কথা বলছে । কম সংযুক্ত কোড প্রয়োগ করা এবং বোঝার জন্য অগত্যা সহজ নয়।

Comments

যুক্তি 4 দেখুন; আমি দেখতে পাচ্ছি না যে দ্বিতীয়টি কী কম সংযুক্ত হয়েছে।

— m3th0dman

Answer 6

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

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

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

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