সুইফট প্রোটোকল নামকরণ কনভেনশন [বন্ধ]

Question

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

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

দ্রুত প্রোটোকলের জন্য নামকরণের সম্মেলনে কোনও চিন্তা?

Comments

meta.programmers.stackexchange.com/questions/6582/...

— মশা

সাধারণভাবে একটি প্রোটোকল নামে ব্যবহৃত পরিভাষাগুলির একটি ক্ষমতা প্রকাশ করা উচিত। Equatableক্লাস সমীকরণ করা যায়, NSCopyingক্লাস অনুলিপি করা যায় ইত্যাদি ইত্যাদি একমাত্র ব্যতিক্রম মনে আসে যে প্রতিনিধি এবং ডেটা উত্স, যা হয় SomethingDelegateবা হয় SomethingDataSource। আমি মনে করি পার্থক্য হ'ল নিজস্ব ক্লাসগুলির মতো কিছু থাকবে var dataSource: SomethingDataSourceতবে আপনি এর মতো কিছু দেখতে পাবেন না var foo: Equatable।

— বেন লেগিগিরো

Answer 1

এই উত্তরটি লেখা হওয়ার পরে বছরগুলিতে সুইফট যথেষ্ট পরিপক্ক হয়েছে। নকশার নির্দেশিকা এখন উল্লেখ করেছে :

• প্রোটোকল যা কিছু যা বর্ণনা করে সেগুলি বিশেষ্য (যেমন Collection) হিসাবে পড়া উচিত ।

• প্রোটোকলের একটি বর্ণনা সামর্থ্য প্রত্যয় ব্যবহৃত হয়ে করা উচিত able, ibleঅথবা ing(যেমন Equatable, ProgressReporting)।

এটি সন্ধানের জন্য ডেভিড জেমসকে ধন্যবাদ!

আসল উত্তর

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

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

ক্লাস এবং প্রোটোকল নাম

প্রোটোকলগুলি কীভাবে আচরণগুলি গোষ্ঠীভুক্ত করে তার নামকরণ করা উচিত:

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

  NSLocking- ভাল.
  NSLock- দরিদ্র (একটি শ্রেণীর নাম বলে মনে হচ্ছে)।

• কিছু প্রোটোকল অনেকগুলি সম্পর্কযুক্ত পদ্ধতি (বিভিন্ন পৃথক ছোট প্রোটোকল তৈরির পরিবর্তে) গোষ্ঠীভুক্ত করে। এই প্রোটোকলগুলি এমন কোনও শ্রেণীর সাথে যুক্ত হতে থাকে যা প্রোটোকলের মূল অভিব্যক্তি। এই ক্ষেত্রে, সম্মেলনটি প্রোটোকলটিকে ক্লাসের মতো একই নাম দেওয়া হয়।

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

তবে দ্বিতীয় দফার পরামর্শ আর প্রযোজ্য নয়:

ক্লাস এবং প্রোটোকলের NSObjectনাম স্থানটি সুইফটে একীভূত হওয়ার কারণে, অবজেক্টিভ-সি-তে প্রোটোকলটি সুইফটে পুনরায় তৈরি করা NSObjectProtocolহয়েছে। ( উত্স )

এখানে, …Protocolপ্রত্যয়টি ক্লাস থেকে প্রোটোকল ছিন্ন করতে ব্যবহৃত হয়েছিল।

সুইফট স্ট্যান্ডার্ড লাইব্রেরী প্রোটোকল রয়েছে Equatable, Comparableএবং Printable। এগুলি কোকো "… ইনিং" ফর্মটি ব্যবহার করে না, বরং এই ধরণের যে কোনও উদাহরণ অবশ্যই একটি নির্দিষ্ট ক্রিয়াকলাপ সমর্থন করবে তা ঘোষণা করার জন্য "... সক্ষম" প্রত্যয়টি ব্যবহার করে না।

---

উপসংহার

কয়েকটি ক্ষেত্রে যেখানে একটি প্রোটোকলের কেবল একটি প্রাসঙ্গিক বাস্তবায়ন থাকে, একটি "… প্রোটোকল" প্রত্যয়টি বোধগম্য করতে পারে যাতে ক্লাস এবং প্রোটোকলের একই নাম থাকতে পারে। তবে এটি কেবল এই জাতীয় ক্ষেত্রে সীমাবদ্ধ হওয়া উচিত।

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

নাম EquatableProtocolহয় সুপারিশের না । নাম Equatableবা Equatingআরও ভাল হবে, এবং আমি আশা করি না যে কোনও শ্রেণীর নাম থাকবে Equatable। এই ক্ষেত্রে, Protocolপ্রত্যয়টি শব্দ হয়।

Comments

FooDelegate এছাড়াও সাধারণ (কমপক্ষে প্রতিনিধিদের জন্য, যা প্রায় সর্বদা প্রোটোকল ... সম্ভবত বাস্তবে সর্বদা থাকে)

— স্ট্রিপস

প্রতি সুইফট এপিআই নকশার গাইডলাইন: swift.org/docamentation/api-design- رہنما নির্দেশিকা >> প্রোটোকলগুলিতে যা কিছু বর্ণনা করে তা বিশেষ্য হিসাবে পড়তে হবে (যেমন সংগ্রহ)) >> সক্ষমতার বর্ণনা দেয় এমন প্রোটোকলগুলি সক্ষম, ible, বা ing (যেমন সমতুল্য, প্রগ্রেস রিপোর্টিং) প্রত্যয় ব্যবহার করে নামকরণ করা উচিত।

— ডেভিড জেমস

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

— ওয়াজিয়াচ কুলিক

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

— আমন

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

— আমন