আমি লিখি প্রতিটি ক্লাসের একটি ইন্টারফেস মেনে চলা উচিত?

Question

আমি টাইপস্ক্রিপ্টে একটি গেম লিখছি, এবং সিদ্ধান্ত নিয়েছি যে আমি " ইন্টারফেস ভিত্তিক প্রোগ্রামিং " ধারণাটি মেনে চলার চেষ্টা করতে যাচ্ছি , যেখানে আপনি কোনও বস্তুর প্রয়োগের পরিবর্তে কোনও ইন্টারফেসের ভিত্তিতে কোড লেখেন।

আমি বেশ কয়েকটি ইন্টারফেস লিখেছি এবং ক্লাসগুলি সেগুলি প্রয়োগ করে, তারপরে একটি পদক্ষেপ নিয়েছিল এবং বুঝতে পেরেছিল যে ক্লাসগুলি যথেষ্ট সহজ ছিল যে আমার সম্ভবত বাস্তবায়ন পরিবর্তন করার দরকার নেই, যেহেতু এটি করার একমাত্র উপায় আছে বর্গটি করে ( Phaser.Spriteএকটি সীমাবদ্ধ উপায়ে একটি ট্যাঙ্কের মতো কাজ করার জন্য)।

তারপরে আমার মনে আছে কয়েক বছর আগে YAGNI এর ধারণা সম্পর্কে পড়া যা মূলত হ'ল আপনি কখনই ব্যবহার করতে পারবেন না এমন জিনিসগুলি অন্তর্ভুক্ত করার জন্য আপনার কোডটি অতিরিক্ত ইঞ্জিনিয়ার করা উচিত নয়।

সর্বোত্তম অনুশীলনগুলি অনুসরণ করে, প্রতিটি শ্রেণির একটি ইন্টারফেস বাস্তবায়ন করা উচিত, না আপনি ভবিষ্যতে সম্ভাব্যভাবে সরিয়ে নেওয়া আশা করেন এমন ক্লাসগুলির মধ্যে সীমাবদ্ধ রাখবেন?

Comments

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

— অ্যান্ডি

প্রতিটি ক্লাসে একটি ইন্টারফেস যুক্ত করার প্রয়োজনীয়তার

— জিএনটি

Answer 1

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

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

এখন ... এটি কেবল তখনই কার্যকর যদি আপনার একই পদ্ধতিতে কাজ করার জন্য একাধিক উত্তরাধিকার শৃঙ্খলার প্রয়োজন হয়, বা আপনার যদি সাধারণ ব্যবহারের সাথে অনেকগুলি বেস ক্লাস থাকে যা আপনি অন্যান্য ব্যবহারকারীদের কাছে যেতে চান।

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

Comments

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

— টিএমএন

Answer 2

আপনি যদি সত্যিই ইন্টারফেসের প্রয়োজন কিনা তা নিশ্চিত না হন, তবে সম্ভবত আপনি তা করবেন না। এটিই ইয়াজিএনআই নীতির মূল বিষয়। আপনার যখন বাস্তবায়নটি অদলবদল করতে সক্ষম হতে হবে তখন আপনি একটি ইন্টারফেসটি প্রবর্তন করবেন।

Answer 3

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

আমরা সাধারণত " interfaceকীওয়ার্ড ব্যবহার করে একটি জাভা ক্লাস সংজ্ঞায়িত করা " বা "শুধুমাত্র জনসাধারণের, খাঁটি ভার্চুয়াল ফাংশন সহ একটি সি ++ শ্রেণি " বোঝাতে "ইন্টারফেস" ব্যবহার করি । এগুলি দরকারী বিমূর্ততা, কারণ এটি কোনও শ্রেণীর ইন্টারফেসটিকে এর বাস্তবায়ন থেকে ডিকুয়াল করে।

এটি মাথায় রেখে, উপযুক্ত হলে ইন্টারফেস ব্যবহার করুন।

• ইন্টারফেসের জন্য কি একাধিক বাস্তবায়ন হবে? যদি তা হয় তবে এই পরিস্থিতিটি একটি ইন্টারফেসে সাধারণ, জন-মুখোমুখি পদ্ধতিগুলি বের করার জন্য প্রার্থী হতে পারে।

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

উপরের নিসেলের শব্দগুলি লক্ষ্য করুন: "প্রার্থী হতে পারে", "দরকারী" হতে পারে। এমন কোনও কঠোর এবং দ্রুত নিয়ম নেই যা প্রদত্ত পরিস্থিতির জন্য "হ্যাঁ" বা "না" বলে।

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

interface I {
  int getA()
  int getB()
  ...
  int getY()
  int getZ()
}

class C : I {
  int getA() { ... }
  int getB() { ... }
  ...
  int getY() { ... }
  int getZ() { ... }
}

Comments

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

— মধ্যে Darien

@ ড্যারিন: পরীক্ষার ব্যবস্থাটির ইন্টারফেসের প্রয়োজন হওয়ার কারণটি হ'ল পরীক্ষাটি আসলে একটি ভিন্ন (বিদ্রূপযুক্ত) বাস্তবায়ন ব্যবহার করে, যখন আপনাকে কোনও ইন্টারফেসের উপযুক্ত হওয়ার প্রথম বুলেটে ফিরিয়ে আনে।

— বার্ট ভ্যান ইনজেন শেহেনো

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

— রবি ডি

@ রবিডি দেখুন এটি জাভা যেমন: জাভা যেমন interfaceঠিক তেমন ঘটে তবে জাভাতে থাকা সমস্ত interfaceকিছুই এর জনসাধারণের মুখোমুখি ইন্টারফেস (ওও ধারণা) হিসাবে ঘটে ।

সবাই! উত্তরের ২ য় এবং ৩ য় বাক্যটি লিখে রাখুন। এটি স্তরিত করুন। এটি আপনার মানিব্যাগে রাখুন। রেফারেন্স প্রায়শই।

— রাডারবব

Answer 4

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

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

মজাদার ফ্রেমওয়ার্ক

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

ইনজেকশন নির্ভরতা

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

---

এই পন্থাগুলি সলাইড নীতিগুলি থেকে ডিতে সংক্ষিপ্তসারিত হয় । এর ঘষাটি হল - বিমূর্ত ব্যবহার করুন, কনক্রেশন নয়।

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

Comments

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

— সারা

@ কাই "আপনি আইওসি পাত্রে ব্যবহার না করে ডিআই ব্যবহার করতে পারেন" । আমি মনে করি আরও পরিপক্ক বিকাশের দোকানগুলি (এবং করতে পারে)। বাহ্যিকভাবে একটি সহজ ধারণা যা আছে তার জন্য কোডকে দূষিত করার দরকার নেই। জোলও একই রকম দৃষ্টিভঙ্গির।

— রবি ডি

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

— রিপাল বারোট