জাভাতে ইন্টারফেসের নামকরণ [বন্ধ]


324

বেশিরভাগ ওও ভাষাগুলি তাদের ইন্টারফেসের নামগুলি মূলধন I এর সাথে উপসর্গ করে, কেন জাভা এটি করে না? এই সম্মেলনটি অনুসরণ না করার যুক্তি কী ছিল?

আমি কী বোঝাতে চাইছি তা বোঝানোর জন্য, যদি আমি একটি ব্যবহারকারী ইন্টারফেস এবং ব্যবহারকারীর প্রয়োগ করতে চাই তবে আমার জাভাতে দুটি পছন্দ থাকতে হবে:

  1. শ্রেণি = ব্যবহারকারী, ইন্টারফেস = ইউজার ইন্টারফেস
  2. ক্লাস = ইউজারআইএমপিএল, ইন্টারফেস = ব্যবহারকারী

যেখানে বেশিরভাগ ভাষায়:

শ্রেণি = ব্যবহারকারী, ইন্টারফেস = আইউজার

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

সুতরাং, আমি অনুমান করি যে আমার প্রশ্নটি এটিকে উত্থিত করে: "বিশেষত জাভা ফ্রেমওয়ার্কগুলি যেদিকে যাচ্ছে বলে মনে হচ্ছে, সেই বিস্তৃত ইন্টারফেস নামকরণ কনভেনশনটি অনুসরণ করা কি উপযুক্ত?"


61
"বেশিরভাগ ভাষায় কোথায়"? । নেট ছাড়াও কোন ভাষা?
wd

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

4
ইলিপস একটি উল্লেখযোগ্য আউটলেটর যা জাভা IFoo শৈলীর নামকরণ সহ ব্যবহার করে। wiki.eclipse.org/ নামকরণ_সংবিধান
ডেভিড লিওনার্ড

2
আপনি (জাভা পাশাপাশি) অ্যান্ড্রয়েড SDK এর মধ্যে ইন্টারফেস নাম কটাক্ষপাত করা থাকে, তাহলে আপনি যে তারা একটি ইন্টারফেস নামের শেষে শব্দ ইন্টারফেস থাকে, ও মত কনভেনশন ব্যবহৃত দেখতে হবে NetworkInterface, DialogInterfaceইত্যাদি
sandalone

21
যখন এই প্রশ্নটি এত জনপ্রিয় এবং এত লোকের আগ্রহের বিষয় তখন কীভাবে "গঠনমূলক না হিসাবে বন্ধ করা যায়"?
ইনর

উত্তর:


329

আমি ইন্টারফেসে একটি উপসর্গ ব্যবহার না করা পছন্দ করি:

  • উপসর্গ পাঠযোগ্যতা ব্যথা করে।

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

  • একটি বিমূর্ত শ্রেণি থেকে একটি ইন্টারফেসে উপসর্গ সহ একটি কোডিং কনভেনশন পরিবর্তন করার সময় আমি ক্লাসের সমস্ত উপস্থিতির নাম বদলে দেওয়ার বোঝাচ্ছি --- ভাল নয়!


12
সম্পূর্ণ একমত. আপনি স্বতঃসম্পূর্ণতা ব্যবহার করেন তবে টাইপ করতে আরও একটি কী। আই এর সাহায্যে প্রচুর ফাইল শুরু হচ্ছে
ক্যালেসার

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

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

11
তদুপরি, আপনি যদি আইএফইওর পথে যাচ্ছেন, তবে এটি বাস্তবায়নের জন্য সিএফও হওয়া উচিত নয় এবং অবশ্যই ব্যর্থতায় কোনও পদ্ধতি কোনও EFoo নিক্ষেপ করবে।
রবিন

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

121

এর মধ্যে আসলেই কি পার্থক্য রয়েছে:

class User implements IUser

এবং

class UserImpl implements User

সব আমরা যদি কথা বলছি নিয়মাবলী নামকরণ?

ব্যক্তিগতভাবে আমি ইন্টারফেসটির Iকোডিং করতে চাই বলে আমি ইন্টারফেসের পূর্ববর্তী অগ্রাধিকার পছন্দ করি না এবং নামকরণের সম্মেলনের ক্ষেত্রে আমি এটিকে আরও গুরুত্বপূর্ণ বলে বিবেচনা করি । আপনি যদি ইন্টারফেসটি কল করেন IUserতবে class শ্রেণীর প্রতিটি গ্রাহককে এটির একটি জানা দরকার IUser। আপনি যদি ক্লাসটি কল করেন UserImplতবে কেবল শ্রেণি এবং আপনার ডিআই কনটেইনর সেই Implঅংশটি সম্পর্কে জানেন এবং গ্রাহকরা কেবল জানেন যে তারা একটি নিয়ে কাজ করছেন User

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

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

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

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

4
@ মার্কার, ইন্টারফেসটি ইঙ্গিত করার জন্য এটি আমার মতো নয়। ডিএও আপনাকে জানায় যে ক্লাস বা ইন্টারফেস হ'ল ডেটা অ্যাক্সেসের জন্য একটি অবজেক্ট, যা বস্তুটি তা করে। আমি আপনাকে এটির একটি ইন্টারফেস বলি, যার নিজের সাথে বস্তুর সাথে কিছুই করার নেই তবে ভাষার শব্দার্থবিদ্যা
tddmonkey

আপনি এটি উপস্থাপন করার সাথে এর উপসর্গ বনাম প্রত্যয়।
আন্দ্রে রিনিয়া

3
@ আন্ড্রেই: না, এটি শব্দার্থক ("ডিএও") বনাম কোনও ভাষা শৈল্পিকের অপ্রয়োজনীয় সজ্জা (ইন্টারফেস হিসাবে "আমি"; একটি সত্য, যা কোডে "ইন্টারফেস আইএফও ..." হিসাবে উল্লিখিত হয়েছে)
ডিস্ক

75

জাভা সাধারণত IUser কনভেনশন ব্যবহার না করার বিভিন্ন কারণ থাকতে পারে।

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

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

  3. জাভা নামকরণ কনভেনশনটি হাঙ্গেরিয়ান ধাঁচের উপসর্গের প্রকৃত অর্থ সহ দীর্ঘ নাম পছন্দ করে। সুতরাং সেই কোডটি যতটা সম্ভব পঠনযোগ্য হবে: একটি তালিকা একটি তালিকা উপস্থাপন করে এবং কোনও ব্যবহারকারী কোনও ব্যবহারকারীর প্রতিনিধিত্ব করে - কোনও আইইউসার নয়।


72

আরও একটি কনভেনশন রয়েছে, যা স্প্রিং সহ অনেকগুলি মুক্ত উত্স প্রকল্প দ্বারা ব্যবহৃত হয়।

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

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


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

47

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

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

কখনও কখনও কোনও বিশেষণটি বোঝায় না, তবে আমি সাধারণত মডেল আচরণ, ক্রিয়া, ক্ষমতা, বৈশিষ্ট্য, ইত্যাদি ইত্যাদির জন্য ইন্টারফেস ব্যবহার করতাম ... প্রকার নয়।

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

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


আমি মনে করি আপনি "বিশেষণ হিসাবে ইন্টারফেস" সমর্থন করার জন্য যে উদাহরণ সরবরাহ করেছেন সেগুলি স্কিউড, যেহেতু এই ইন্টারফেসগুলি আরও মিক্স-ইনগুলি (বা বৈশিষ্ট্যগুলি) এর মতো হ'ল। সুতরাং, ইন্টারফেস দুটি বিশেষণ এবং বিশেষ্য উভয়ের জন্যই ভাল - তবে সম্ভবত indefinite transitive verbs 8 ^ পি এর জন্য নয়

এটি গত বছরগুলিতে পরিবর্তিত হতে পারে। ওরাকল ডকুমেন্ট। ধরনের হিসাবে ইন্টারফেস অনুমতি দেয়: [লিঙ্ক] ডকস.অরাকল.com
জাভ্যাস /

38

বব লি একবার উপস্থাপনায় বলেছিলেন:

ইন্টারফেসের মূল বিষয় কী যদি আপনার কেবলমাত্র একটি বাস্তবায়ন থাকে।

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

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

সুতরাং এটি পরিষ্কার হয়ে যায় -> ইন্টারফেস ব্যবহারকারীর প্রয়োগকরণ ব্যবহারকারীআইএমপিএল।


18
ইন্টারফেস ব্যবহার ড্রাইভ বিকাশের পরীক্ষা করতে সহায়তা করে। আমরা ডোমেন মডেল এবং পরীক্ষা নিয়ে অসংখ্য সমস্যার সমাধান করেছি কারণ আমরা ইন্টারফেস ব্যবহার না করার সিদ্ধান্ত নিয়েছিলাম। আমার এক বন্ধু একবার উদ্ধৃত হয়েছিল: "সবকিছুই একটি ইন্টারফেস, এটি আপনাকে দীর্ঘমেয়াদে বাঁচায়।"
hooknc

4
উপহাস এবং সহজ প্রক্সি সমর্থন। আমি নিশ্চিত যে ইন্টারফেস সরবরাহ করার অন্যান্য কারণও রয়েছে।
MetroidFan2002

3
যেমন আমি সম্প্রতি একজন সহকর্মীকে বলেছিলাম, এখনই ইন্টারফেসটি প্রবর্তন করতে কিছু খরচ হয় না তবে পরে আপনার প্রচুর সময় সাশ্রয় করতে পারে।
tddmonkey

2
নিকট-মাঝারি ভবিষ্যতে আপনার যদি অন্য বাস্তবায়ন হতে পারে তবে একটি ইন্টারফেসটি একটি প্লাস হবে।
স্টিপ

3
"ভবিষ্যতে আমার আর একটি প্র্রয়োজনের প্রয়োজন হতে পারে" যুক্তিটি আমার পছন্দ নয়। আমি একটি YAGNI পদ্ধতির পছন্দ করি: এখনও ঘটেনি এমন জিনিসগুলির জন্য পরিকল্পনা করবেন না।
ডেভিড ল্যাভেন্ডার

24

সি # তে এটি

public class AdminForumUser : UserBase, IUser

জাভা বলতেন

public class AdminForumUser extends User implements ForumUserInterface

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


22
হতে পারে আমি খারাপ জাভা কোডার, তবে আমি সি # স্টাইল পছন্দ করি, এর অর্থ সমস্ত ইন্টারফেসগুলি 'আমি' উপসর্গ দিয়ে শুরু হয় :)
ডেভ

7
আমি নিশ্চিত নই যে আপনি এবং অন্যরা এই অনুমিত সম্মেলনটি কোথা থেকে পাচ্ছেন। জাভা লাইব্রেরিতে এটি স্পষ্ট নয় ...
চিফ টুপেনসিলস

6

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

উদাহরণস্বরূপ, আপনার ক্ষেত্রে, আমি কেবলমাত্র IUserকেবলমাত্র আপনিই চান এমন একমাত্র ব্যবহারকারী কিনা তা দেখার আশা করব User। যদি আপনি বিভিন্ন ধরণের ব্যবহারকারী - NoviceUser, ExpertUserইত্যাদি ইত্যাদি রাখার পরিকল্পনা করেন - আমি একটি Userইন্টারফেস (এবং সম্ভবত একটি AbstractUserশ্রেণি যা কিছু সাধারণ কার্যকারিতা কার্যকর করে যেমনget/setName() ) দেখার আশা করব।

আমিও ইন্টারফেসগুলি যে ক্ষমতা নির্ধারণ আশা - Comparable, Iterableইত্যাদি - যে মত নামে করা এবং অন্য কোনো না IComparableবা IIterable


আপনি যদি কেবলমাত্র একমাত্র ব্যবহারকারীকেই ব্যবহারকারী করতে চান তবে কেবল ইন্টারফেসের পরিবর্তে ব্যবহারকারী ব্যবহার করবেন না কেন?
ক্যারিখন

3
কিছু ক্লায়েন্ট / সার্ভার আর্কিটেকচারে ক্লায়েন্ট পক্ষের হেভিওয়েট সার্ভার প্রয়োগকরণের প্রয়োজন ছাড়াই ইন্টারফেসগুলি জানতে হবে।
ডেভিড কোয়েল 10'17

5

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

public void doSomething(Collection someStuff) {
    ...
}

এই তুলনায়:

public void doSomething(Vector someStuff) {
    ...
}

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

কোডের একমাত্র বিট যা প্রকৃত কংক্রিট শ্রেণিগুলির যত্ন নেওয়া উচিত সেগুলি হ'ল কংক্রিটের ক্লাসগুলি নির্মিত are ইন্টারফেস ব্যবহার করে অন্য সব কিছু লেখা উচিত।

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


আপনি যখন কেবল একটি বা দুটি জিনিসের জন্য ইন্টারফেসের প্রয়োজন তখন আপনার প্রোগ্রামের প্রতিটি শ্রেণীর জন্য একটি ম্যাচিং ইন্টারফেস তৈরি করা কেন বিরক্ত করবেন?
কিংবদন্তি লেন্থথ

3

= v = উইকেটের কাঠামোয়, "আমি" উপসর্গটিও ব্যবহৃত হয়, যেখানে আমি এটির অভ্যস্ত হয়ে গেলাম। সাধারণভাবে, আমি এমন কোনও সম্মেলনকে স্বাগত জানাই যা ভারী জাভা ক্লাসের নামগুলি সংক্ষেপিত করে। এটি একটি ঝামেলা, যদিও, ডিরেক্টরিগুলিতে এবং জাভাদোক-এ "I" এর অধীনে সবকিছু বর্ণমুক্ত।

উইকেট কোডিং অনুশীলনটি সুইংয়ের অনুরূপ, অনেকগুলি নিয়ন্ত্রণ / উইজেট উদাহরণগুলি ইনলাইন পদ্ধতি ঘোষণার সাথে বেনামে অভ্যন্তরীণ শ্রেণি হিসাবে নির্মিত হয়। বিরক্তিকরভাবে, এটি সুইং থেকে 180 dif এর থেকে পৃথক হয় যে বাস্তবায়নকারী ক্লাসগুলির জন্য সুইং একটি উপসর্গ ("জে") ব্যবহার করে।

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


0

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

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

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