বিদ্যমান অবজেক্টগুলিতে এক্সটেনশন যুক্ত সুইফট ফাইলের নামকরণের জন্য সেরা অনুশীলন কোনটি?

Question

ভাষার স্পেসিফিকেশনে বর্ণিত হিসাবে এক্সটেনশনগুলি ব্যবহার করে বিদ্যমান সুইফট অবজেক্টের ধরণের এক্সটেনশান যুক্ত করা সম্ভব ।

ফলস্বরূপ, এক্সটেনশনগুলি তৈরি করা সম্ভব যেমন:

extension String {
    var utf8data:NSData {
        return self.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: false)!
    }
}

তবে, এই জাতীয় এক্সটেনশনগুলি থাকা সুইফট উত্স ফাইলগুলির জন্য নামকরণের সেরা অনুশীলনটি কী?

অতীতে কনভেনশনটি extendedtype+categoryname.mউদ্দেশ্য-সি প্রকারের জন্য অবজেক্টি-সি গাইড হিসাবে আলোচিত হিসাবে ব্যবহার করা হয়েছিল । তবে সুইফ্ট উদাহরণটির কোনও বিভাগের নাম String.swiftনেই এবং এটি কল করা উপযুক্ত বলে মনে হয় না।

সুতরাং প্রশ্নটি হল: উপরের Stringএক্সটেনশানটি দেওয়া হলে সুইফট উত্স ফাইলটি কী বলা উচিত?

Comments

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

— আলব্লিউ

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

— কোডাফাই

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

— অ্যান্ড্রু

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

— AlBlue

একটি একক এক্সটেনশানসইউফ্ট ফাইলটি আমার মতে যাওয়ার উপায়। আপনার যা সহজে প্রয়োজন তা সন্ধান করার জন্য এর অভ্যন্তরের কাঠামোটি সুসংহত করুন (আপনার নিজের উপায়ে)। একটি একক ফাইল বিভিন্ন প্রকল্পের অনুলিপি বা লিঙ্ক করা সহজ এবং স্টাফ ভুলবেন না।

— ইয়াহস্ট

Answer 1

বেশিরভাগ উদাহরণ আমি লক্ষ্য করেছি- উদ্দেশ্য-সি পদ্ধতির নকল করছি। উপরের উদাহরণ এক্সটেনশনটি হ'ল:

String+UTF8Data.swift

সুবিধাগুলি হ'ল নামকরণের কনভেনশনটি এটি বোঝা সহজ করে তোলে যে এটি একটি এক্সটেনশন এবং কোন শ্রেণিটি বাড়ানো হচ্ছে।

ব্যবহার Extensions.swiftবা এমনকি StringExtensions.swiftএটির ক্ষেত্রে সমস্যাটি হ'ল ফাইলের বিষয়বস্তু না দেখে তার নাম দিয়ে ফাইলটির উদ্দেশ্য নির্ধারণ করা সম্ভব নয়।

ব্যবহার xxxable.swiftযেমন জাভা দ্বারা ব্যবহৃত পদ্ধতির প্রোটোকল বা এক্সটেনশান যে শুধুমাত্র পদ্ধতি নির্ধারণ জন্য ঠিক কাজ করে। তবে আবার, উপরের উদাহরণটি একটি বৈশিষ্ট্যকে সংজ্ঞায়িত UTF8Dataable.swiftকরে যাতে ব্যাকরণগত কোনও ধারণা তৈরি হয় না।

Comments

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

— ইয়াহস্ট

এই উত্তরটি, <নাম> + <এক্সটেনশন>। সুইফট, এক্সকোডে কোর ডেটার জন্য NSManagedObject সাবক্ল্যাস তৈরি করার সময় Xcode আসলে এটিই করে Example উদাহরণ: Foo + CoreDataProperties.swift।

— জেরি ক্রিনক

এক্সটেনশন একাধিক পদ্ধতি প্রয়োগ করে তবে কী হবে?

— অ্যালেক্সভিপার্ল

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

— পিকিয়ানো

আপনি যদি কনভেনশনটি ব্যবহার করে থাকেন তবে ExtendedType+Functionality.swift, সমস্ত Stringএক্সটেনশানগুলি উদাহরণস্বরূপ, ফোল্ডারের নীচে তাদের নিজস্ব সাবফোল্ডার (অর্থাৎ Stringবা String Extensions) এর মধ্যে বাছাই করা কি ভাল অনুশীলন Extensions? অথবা কেবলমাত্র সমস্ত এক্সটেনশন ফাইলগুলি Extensionsফোল্ডারের নীচে একই স্তরে সংরক্ষণ করা ভাল ?

— নোহ ওয়াইল্ডার

Answer 2

কোনও সুইফট কনভেনশন নেই। সহজবোধ্য রাখো:

StringExtensions.swift

আমি বর্ধিত প্রতিটি শ্রেণীর জন্য একটি ফাইল তৈরি করি। আপনি যদি সমস্ত এক্সটেনশনের জন্য একটি একক ফাইল ব্যবহার করেন তবে তা দ্রুত একটি জঙ্গলে পরিণত হবে।

Comments

এটি বিশেষভাবে পুনরায় ব্যবহারযোগ্য বলে মনে হচ্ছে না।

— কেলার

তুলনামুলকভাবে?

— মাইক টাভের্ন

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

— কেলার

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

— মাইক Taverne

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

— মার্ক এ। ডোনোহো

Answer 3

আমি পছন্দ StringExtensions.swiftনা হওয়া পর্যন্ত আমি ভালো কিছু মধ্যে ফাইল বিভক্ত করতে অত্যধিক জিনিষ যোগ String+utf8Data.swiftএবং String+Encrypt.swift।

আরও একটি বিষয়, একই ফাইলগুলিকে একের সাথে সংযুক্ত করা আপনার বিল্ডিং আরও দ্রুততর করে তুলবে। পড়ুন নিখুঁত-সুইফট-বিল্ড টাইমস

Comments

একই জিনিসটির জন্য দুটি ফাইলের নামকরণের কনভেনশন রয়েছে। আমি মনে করি এটি খারাপ।

— অর্থ-বিষয়গুলি

@ অর্থ-বিষয় এটি নির্ভর করে। দুটি নামকরণ কনভেনশন উভয়ই অ্যাপল ডকুমেন্টস দ্বারা সুপরিচিত এবং প্রস্তাবিত। তোমার যা ইচ্ছা করো.

— ডনসং

আমি আশা করি আরও প্রোগ্রামার নামকরণ এবং কোড [ফর্ম্যাটিং] প্রকরণকে সীমাবদ্ধ রেখে কমনীয়তার জন্য চেষ্টা করবে।

— অর্থ-বিষয়গুলি

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

— ডনসং

আমি ধারাবাহিকতার কমনীয়তা বোঝাতে চাইছিলাম: এক্সটেনশনের নামকরণের একটি উপায় বা কোঁকড়া ধনুর্বন্ধনী রাখার একটি উপায় ব্যবহার করে। তারপরে আমি ভাবি যে বিভিন্ন কোঁকড়া ধনুর্বন্ধনী শৈলীর পাঠযোগ্যতার মধ্যে একটি পরিমাপযোগ্য পার্থক্য রয়েছে; সুতরাং আমি একেবারেই 'তুচ্ছ' মনে করি না।

— অর্থ-বিষয়গুলি

Answer 4

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

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

protocol CloudAdapterProtocol: ReggyCloudProtocol, ProReggyCloudProtocol {
    var server: CloudServer {
        get set
    }
    func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void)
}

ইন Server.swiftআমার আছে

import Foundation
import UIKit
import Alamofire
import AlamofireImage

class Server: CloudAdapterProtocol {
.
.
func getServerApiVersion(handler: @escaping (String?, Error?) -> Swift.Void) {
.
.
}

Server.swiftতারপরে সার্ভার সেট করার জন্য এবং API সংস্করণটি পাওয়ার জন্য কেবল মূল সার্ভার এপিআই প্রয়োগ করে। আসল কাজটি দুটি ফাইলে বিভক্ত:

Server_ReggyCloudProtocol.swift
Server_ProReggyCloudProtocol.swift

এগুলি সংশ্লিষ্ট প্রোটোকলগুলি প্রয়োগ করে।

এর অর্থ আপনার অন্যান্য ফাইলগুলিতে আমদানির ঘোষণা থাকা দরকার (এই উদাহরণে অ্যালামোফায়ারের জন্য) তবে এটি আমার দৃষ্টিতে পৃথক ইন্টারফেসের ক্ষেত্রে এটি একটি পরিষ্কার সমাধান।

আমি মনে করি এই পদ্ধতিটি আপনার নিজস্ব হিসাবে বাহ্যিকভাবে নির্দিষ্ট ক্লাসগুলির সাথে সমানভাবে ভাল কাজ করে।

Answer 5

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

Comments

আমার ক্ষেত্রে, আমি মনে করি যে ইউআইভিউএক্সটেনশন নামে পরিচিত একটি ফাইল থাকা আমাদের সঠিক ধারণাটি তৈরি করে s সুইচটি সেই ফাইলটিতে সংজ্ঞায়িত এক্সটেনশনগুলি যে কোনও / সমস্ত ইউআইভিউ ক্লাস যেমন 'প্লেসইইন (ইউআইভিউ)' পদ্ধতির জন্য অর্থবোধ করে provided যদি এটি ব্যবহার-নির্দিষ্ট হয় (যেমন কেবল অ্যাপ্লিকেশানের কোনও অংশের জন্য, কাস্টম ভিউ সাজসজ্জার আশেপাশে বলুন, তবে আমি ইউআইভিউ + কাস্টম ডেকোরেশন.সুইফ্ট করব Point পয়েন্ট হ'ল 'ইউআইভিউ এক্সটেনশনস' নামক কোনও ফাইল বলার মতো সাধারণীকরণের আগে আপনাকে ব্যবহার বিবেচনা করতে হবে) .সভিট যে কোনও উদ্দেশ্য প্রকাশ করে না 'যখন উদ্দেশ্যটি সমস্ত ইউআইভিউর জন্য সাধারণ এক্সটেনশান হয়

— মার্ক এ। ডোনোহো

Answer 6

আমার জায়গাটি জুড়ে আমার মন্তব্যগুলি যুক্ত করার পরিবর্তে, আমি এখানে একটি উত্তরে সেগুলি সারফেস করছি।

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

উদাহরণস্বরূপ, কিছু তোলে অনুভূতি উপলব্ধ করা কোন স্ট্রিং যেতে হবে StringExtensions.swiftযেমন trimRight()এবং removeBlankLines()।

যাইহোক, যদি আমি একটি এক্সটেনশন ফাংশন যেমন ছিল formatAsAccountNumber()এটি হবে না যে ফাইল মধ্যে যেতে কারণ 'অ্যাকাউন্ট নম্বর' এমন কিছু বিষয় যা স্বাভাবিকভাবেই কোনো ক্ষেত্রে প্রযোজ্য হবে না / সব স্ট্রিং এবং শুধুমাত্র ইন্দ্রিয় অ্যাকাউন্ট প্রেক্ষাপটে নির্মিত হয়। সেক্ষেত্রে আমি একটি ফাইল কল করে Strings+AccountFormatting.swiftবা সম্ভবত Strings+CustomFormatting.swiftএকটি দিয়ে তৈরি করবformatAsAccountNumber()সেক্ষেত্রে, বেশিরভাগ ধরণের / উপায় থাকলে প্রকৃতপক্ষে এটি ফর্ম্যাট করার জন্য ফাংশন ।

আসলে, এই শেষ উদাহরণে, আমি সক্রিয়ভাবে আমার দলটিকে প্রথম স্থানে এর মতো এক্সটেনশনগুলি ব্যবহার করতে নিষ্ক্রিয় করেছিলাম এবং এর AccountNumberFormatter.format(String)পরিবর্তে এমন কোনও কিছুকে উত্সাহিত করব যা Stringএপিআই পৃষ্ঠের অঞ্চলটিকে স্পর্শ করে না , যেমনটি করা উচিত নয়। ব্যতিক্রম হ'ল যদি আপনি সেই ফাইলটি সেই একই ফাইলটিতে ব্যবহার করেন যেখানে এটি ব্যবহৃত হয়, তবে তবে এটির নিজস্ব ফাইল নাম কোনওভাবেই হয় না।

Answer 7

আমি +এটিতে এক্সটেনশানগুলি রাখার সত্যটিকে নিম্নরেখাঙ্কিত করতে পছন্দ করি :

String+Extensions.swift

এবং যদি ফাইলটি খুব বড় হয়ে যায় তবে আপনি এটি প্রতিটি উদ্দেশ্যে বিভক্ত করতে পারেন:

String+UTF8Data.swift

String+Encrypt.swift