একটি উপাদান এবং একটি মডিউল মধ্যে পার্থক্য আছে কি


31

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

উপাদানগুলির মধ্যে পার্থক্য কী? আমি এটি কয়েকটি বইয়ে দেখেছি, তবে উপাদানগুলির বর্ণনাটি খুব মিল।


5
কোন ভাষা? কোন আর্কিটেকচার? আপনার মডিউল কাজ সংজ্ঞা। আমি এমন একটি উপাদানকে এমন কিছু হিসাবে মনে করি যা কোনও জিইউআই বলতে কিছুকে প্লাগ করে তবে মডিউল কোনও জিইউআইতে প্লাগ করতে পারে না; GUI কনস্ট্রাক্টস দ্বারা মোড়ানো / সমর্থিত হলে মডিউলগুলি একটি জিইউআইতে কাজ করতে পারে।
গাই কোডার

3
দেখুন ক্লাস বনাম কম্পোনেন্ট বনাম কন্ট্রোল নোট: আমি উত্তর নই কারণ আপনার প্রশ্নের langauge বা স্থাপত্য উল্লেখ নেই।
গাই কোডার

হ্যাঁ, এই ক্ষেত্রে, আমি সাধারণভাবে সংজ্ঞাগুলি নিয়ে ভাবি
মিরকো

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

হ্যাঁ, আমি মনে করি আমার প্রশ্নটি খুব সাধারণ এবং উত্তরটি সত্যই ব্যবহৃত ভাষা বা enviornement উপর নির্ভর করে। নার্ভ ভেবেছিলেন এই পদগুলির জন্য এতগুলি আলাদা সংজ্ঞা রয়েছে
মিরকো

উত্তর:


12

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

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


4
সমস্ত উত্তর সত্যিই আমাকে সাহায্য করেছে, তবে আমি কেবল একটি গ্রহণ করতে পারি। তাই আমি কীথসকে মেনে নিচ্ছি কারণ তার সবচেয়ে কম প্রতিনিধি আছে
মিরকো

12

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

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

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


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

9

যদি আমরা নির্দিষ্ট ভাষা, ফ্রেমওয়ার্ক এবং তাদের নিজস্ব ব্যাখ্যা থেকে বিমূর্ত হয়ে থাকে তবে বিমূর্ত সফ্টওয়্যার গ্রানুলারিটি হায়ারার্কিটি নিম্নলিখিত:

Product - application, library, service
  Module - GUI, core logic, data, etc...
    Component - purpose specific collection of objects
      Object - collection of primitives
        Primitive - numbers, functions, etc...
  • প্রোডাক্ট

সাধারণ এবং সরল, পণ্যটি সংযুক্ত ফাংশনাল মডিউলগুলির একটি কার্যকরী সংগ্রহ।

  • মডিউল

খুব নাম থেকেই বোঝা যায় যে মডিউলটির অনুপ্রেরণা হল পরিমিতি। অনেকের দাবির বিপরীতে এটি কোড পুনরায় ব্যবহারের প্রকৃতপক্ষে বোঝায় না। এমন অনেকগুলি মডিউল রয়েছে যা সত্যিই পুনরায় ব্যবহারযোগ্য নয় এবং এমন কোনও কিছুর সাথে খাপ খায় না যা সেগুলি ডিজাইন করা হয়নি।

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

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

  • উপাদান

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

নামটি থেকে বোঝা যায়, মডিউলটির বিপরীতে, উপাদানটি "স্ব-অন্তর্ভুক্ত" নয়, এটি বৃহত্তর কার্যকরী পুরোটির একটি অংশ।

  • উদ্দেশ্য

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

  • আদিম

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

আপনি আদিমদের সাথে খুব সামান্য কিছু করতে পারেন এবং একই সাথে এটি এত কম স্তরে রয়েছে যে আপনি এটি দিয়ে ব্যবহারিকভাবে সমস্ত কিছু সম্পাদন করতে পারবেন। এটি খুব খুব, খুব ভার্বোজ, অত্যন্ত জটিল এবং অসম্ভব ক্লান্তিকরভাবে সরাসরি আদিমদের সাথে কাজ করার সময়।

  • এই সব কি লাভ?

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

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

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

  • পরিভাষা সতর্কতা

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

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


1
আপনার মডিউলটির সংস্করণ প্যাকেজের মতো শোনাচ্ছে।
জেএম বেকার 17

1
@ জেএমবেকার সত্যই নয়, গ্রানুলারিটির ক্ষেত্রে কোনও প্যাকেজ কোনও বস্তুর সংগ্রহ থেকে সম্পূর্ণ স্ট্যান্ডেলোন পণ্য পর্যন্ত যে কোনও কিছু ধারণ করতে পারে। প্যাকেজিং গ্রানুলারিটি চেইনের একটি লিঙ্কের চেয়ে কোড পুনরায় ব্যবহারের জন্য আরও সুবিধাজনক জিনিস thing
dtech

3

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

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

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

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