পদ্ধতিগুলি কি কেবল যুক্তির নাম (টাইপ নয়) দ্বারা আলাদা করা যথেষ্ট?


36

পদ্ধতিগুলির পক্ষে কেবল যুক্তির নাম (টাইপ নয়) দ্বারা আলাদা করা কি যথেষ্ট বা স্পষ্টরূপে নামকরণ করা ভাল?

উদাহরণস্বরূপ T Find<T>(int id)বনাম T FindById<T>(int id)

ByIdকেবল যুক্তি নাম রাখার তুলনায় আরও স্পষ্টভাবে নামকরণের (অর্থাত্ যোগ করা ) কোনও যুক্তিসঙ্গত কারণ আছে কি ?

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

FindByFirstName(string name) এবং FindByLastName(string name)


4
সুতরাং আপনি যখন ওভারলোড করবেন তা অন্তর্ভুক্ত করার জন্য অনুসন্ধান করুন T Find<T>(string name)বা আপনি (int size)কীভাবে অনিবার্য সমস্যাগুলি সমাধান করার পরিকল্পনা করবেন?
ইউকেমনকি

3
@ ইউকেমনেকি কী অনিবার্য সমস্যা?
কনরাড

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

2
@ ইউকেমনকি আপনি চাইলে কিছু কোড উদাহরণ সহ একটি উত্তর পোস্ট করতে পারেন
কনরাড

3
আইডিগুলি সম্ভবত একটি অস্বচ্ছ IDবস্তু হওয়া উচিত এবং কেবল একটি নয় int। এইভাবে সংকলন-সময় পরীক্ষা করে নিন যে আপনি আপনার কোডের কিছু অংশে কোনও আইএনটি বা বিপরীতার জন্য কোনও আইডি ব্যবহার করেন না। এবং এটি দিয়ে আপনি থাকতে পারেন find(int value)এবং find(ID id)
বাকুরিউ

উত্তর:


68

নিশ্চিতভাবেই এর নাম আরও স্পষ্ট করে বলার উপযুক্ত কারণ রয়েছে।

এটি মূলত পদ্ধতি সংজ্ঞা নয় যা স্ব-ব্যাখ্যামূলক হওয়া উচিত, তবে পদ্ধতিটি ব্যবহার । এবং যখন findById(string id)এবং find(string id)উভয় স্বশাসিত হয়, তার মাঝে একটি বিশাল পার্থক্য আছে findById("BOB")এবং find("BOB")। পূর্ববর্তী ক্ষেত্রে আপনি জানেন যে এলোমেলো আক্ষরিক আসলে একটি আইডি। পরবর্তী ক্ষেত্রে আপনি নিশ্চিত নন - এটি সম্ভবত একটি প্রদত্ত নাম বা সম্পূর্ণ অন্য কিছু হতে পারে।


9
99% বাদে যেখানে আপনার ভেরিয়েবল বা সম্পত্তির নাম রয়েছে তার একটি রেফারেন্স পয়েন্ট: findById(id)বনাম find(id)। আপনি এই পথে যেতে পারেন।
গ্রেগ বার্গার্ড

16
@ গ্রেগবার্গার্ড্ট: কোনও পদ্ধতি এবং তার কলারের জন্য একটি নির্দিষ্ট মান অগত্যা একইভাবে নামকরণ করা হয় না। উদাহরণস্বরূপ, বিবেচনা double Divide(int numerator, int denominator)একটি পদ্ধতি ব্যবহৃত হচ্ছে: double murdersPerCapita = Divide(murderCount, citizenCount)। আপনি একই পরিবর্তনশীল নামটি ব্যবহার করে দুটি পদ্ধতির উপর নির্ভর করতে পারবেন না কারণ এমন
অনেকগুলি

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

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

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

36

FindById এর সুবিধা ()

  1. ভবিষ্যত-প্রুফিং : আপনার সাথে শুরু করেন Find(int), এবং পরে অন্যান্য পদ্ধতি (যোগ আছে FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), ইত্যাদি), আমার মত মানুষের বয়সের ব্যয় খুঁজছেন ঝোঁক FindById(int)। সত্যিই নেই একটি সমস্যা যদি আপনি যা করতে পারেন এবং পরিবর্তন করতে হবে Find(int)করতে FindById(int)একবার এটা প্রয়োজনীয় হয়ে - ভবিষ্যত প্রুফিং এই সম্পর্কে যদি সে।

  2. পড়া সহজFindপুরোপুরি জরিমানা যদি মত কল দেখায় record = Find(customerId);তবুও FindByIdপড়া যদি এটা জন্য সামান্য সহজ হয় record = FindById(AFunction());

  3. ধারাবাহিকতা । আপনি ধারাবাহিকভাবে সর্বত্র সর্বত্র FindByX(int)/ FindByY(int)প্যাটার্ন প্রয়োগ করতে পারেন , তবে Find(int X)/ Find(int Y)সম্ভব নয় কারণ এগুলির মধ্যে বিরোধ রয়েছে।

সন্ধানের সুবিধা ()

  • চুমু খেতে হবে। Findসহজ এবং সোজা, এবং পাশাপাশি operator[]এই প্রসঙ্গে 2 সবচেয়ে প্রত্যাশিত ফাংশন নামগুলির মধ্যে একটি। (কিছু জনপ্রিয় বিকল্প হচ্ছে get, lookupঅথবা fetch, প্রসঙ্গ উপর নির্ভর করে)।
  • থাম্বের নিয়ম হিসাবে, যদি আপনার কোনও ফাংশনের নাম থাকে যা একটি একক সুপরিচিত শব্দ যা ফাংশনটি কী করে তা সঠিকভাবে বর্ণনা করে, এটি ব্যবহার করুন। এমনকি যদি দীর্ঘতর বহু-শব্দের নাম থাকে যা ফাংশনটি কী করে তা বর্ণনা করার ক্ষেত্রে কিছুটা ভাল। উদাহরণ: দৈর্ঘ্য বনাম সংখ্যাআফিলিমেটস । একটি ট্রেডঅফ রয়েছে এবং কোথায় লাইনটি আঁকবেন তা চলমান বিতর্কের বিষয়।
  • অপ্রয়োজনীয়তা এড়ানো সাধারণত ভাল। যদি আমরা দেখি FindById(int id), আমরা সহজেই এটিকে পরিবর্তন করে অতিরিক্ত জালিয়াতি অপসারণ করতে পারি Find(int id), তবে একটি বাণিজ্য বন্ধ রয়েছে - আমরা কিছুটা স্পষ্টতা হারাতে পারি।

বিকল্পভাবে আপনি দৃ strongly়ভাবে টাইপ করা আইডি ব্যবহার করে উভয়ের সুবিধা পেতে পারেন :

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

এর বাস্তবায়ন Id<>: সি # তে শক্তভাবে টাইপ করা আইডি মানগুলি

এখানে মন্তব্যগুলি, পাশাপাশি উপরের লিঙ্কে, Id<Customer>আমি যে সম্বোধন করতে চাই সে সম্পর্কে একাধিক উদ্বেগ উত্থাপন করেছে :

  • উদ্বেগ 1: এটি জেনেরিকগুলির অপব্যবহার। CustomerIdএবং OrderIDবিভিন্ন ধরণের ( customerId1 = customerId2;=> ভাল, customerId1 = orderId1;=> খারাপ), তবে তাদের বাস্তবায়ন প্রায় অভিন্ন, তাই আমরা সেগুলি কপির পেস্ট বা রূপান্তরকৃত দ্বারা প্রয়োগ করতে পারি। জেনেরিকটি প্রকাশ বা লুকিয়ে রাখার বিষয়ে আলোচনার মূল্য রয়েছে, তবে জেনেরিকগুলি কী রূপান্তরকৃত তা রূপান্তরকেন্দ্রিক।
  • উদ্বেগ 2: এটা সহজ mistakes./It's একটি সমস্যা সন্ধানে একটি সমাধান থামবে না প্রধান সমস্যাটি যে ব্যবহার শক্তিশালী ভাবে টাইপ Id গুলি একটি কল ভুল যুক্তি অর্ডার দ্বারা সরানো হচ্ছে DoSomething(int customerId, int orderId, int productId)। দৃ OP়ভাবে টাইপ করা আইডি অন্যান্য ওপি সম্পর্কে জিজ্ঞাসা করা সহ অন্যান্য সমস্যাগুলিও প্রতিরোধ করে।
  • উদ্বেগ 3: এটি সত্যিই কেবল কোডটিকে অস্পষ্ট করে। কোনও আইডি রাখা হয়েছে কিনা তা বলা শক্ত int aVariable। এটি সহজেই বলা যায় যে কোনও আইডি রাখা আছে Id<Customer> aVariableএবং আমরা এমনকি এটি বলতে পারি যে এটি একটি গ্রাহক আইডি।
  • উদ্বেগ 4: এই আইডিগুলি কোনও শক্ত ধরণের নয়, কেবল মোড়কে। Stringচারদিকে কেবল একটি মোড়ক byte[]। মোড়ানো, বা এনক্যাপসুলেশন, শক্তিশালী টাইপিংয়ের সাথে বিরোধ নয়।
  • উদ্বেগ 5: এটি ওভার ইঞ্জিনিয়ারড। এখানে সংক্ষিপ্ত সংস্করণটি দেওয়া হল, যদিও আমি যুক্ত করার প্রস্তাব দিই operator==এবং operator!=পাশাপাশি, আপনি যদি একচেটিয়াভাবে নির্ভর করতে না চান তবে Equals:

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

10

এ সম্পর্কে চিন্তাভাবনার আরেকটি উপায় হ'ল ভাষার প্রকার সুরক্ষা ব্যবহার করা।

আপনি কোনও পদ্ধতি প্রয়োগ করতে পারেন যেমন:

Find(FirstName name);

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


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

2
@ ডকব্রাউন আমি উত্তরোত্তরটি মনে করি এবং আমি এটি পছন্দ করি। এটি আসলে পিটারের উত্তরের মতো, আইয়ুক। আমি যেমন বুঝতে পারি তত যুক্তি দ্বিগুণ: (1) ফাংশনটি কী করে তা আর্গুমেন্ট টাইপ থেকে এটি স্পষ্ট; (২) আপনি ভুলগুলি করতে পারবেন না। আপনি string name = "Smith"; findById(name);যদি অন-বিবরণী সাধারণ ধরণের ব্যবহার করেন তবে যা সম্ভব।
পিটার - মনিকা পুনরায় ইনস্টল করুন

5
সাধারণভাবে আমি সংকলন টাইম ধরণের সুরক্ষার অনুরাগী থাকাকালীন, মোড়ক প্রকারের সাথে সতর্ক থাকি। প্রকার সুরক্ষার স্বার্থে মোড়কের ক্লাসগুলি উপস্থাপন করা অতিরিক্ত সময়ে যদি করা হয় তবে আপনার API কে মারাত্মকভাবে জটিল করে তুলতে পারে। উদাহরণস্বরূপ, উইনাপির যে "পুরো শিল্পী পূর্বে ইন্ট" নামে পরিচিত ছিল; দীর্ঘমেয়াদে আমি বলব যে বেশিরভাগ লোকেরা কেবল অন্তহীন DWORD LPCSTRইত্যাদি ক্লোনগুলি দেখে এবং মনে করে "এটি কোনও পূর্ববর্তী / স্ট্রিং / ইত্যাদি", এটি এমন জায়গায় পৌঁছেছে যে আপনি আসলে আপনার ডিজাইনিং কোডের চেয়ে আপনার সরঞ্জামগুলির উত্থাপনে বেশি সময় ব্যয় করেন you ।
জুন

1
@jrh সত্য। "নামমাত্র" প্রকার (শুধুমাত্র নামেই পৃথক) প্রবর্তনের জন্য আমার লিটমাস পরীক্ষাটি যখন সাধারণ ক্রিয়াকলাপ / পদ্ধতিগুলি আমাদের ব্যবহারের ক্ষেত্রে কোনও অর্থ দেয় না, যেমন int, প্রায়শই সংক্ষিপ্ত, গুণিত করা হয়, যা আইডির জন্য অর্থহীন নয়; তাই আমি এর IDথেকে আলাদা করব int। এটি একটি এপিআইকে সহজতর করতে পারে, আমরা কী কী মূল্য দিতে পারি তা সংকুচিত করে (উদাহরণস্বরূপ যদি আমাদের একটি থাকে তবে IDএটি কেবল findউদাহরণস্বরূপ নয়, ageবা এর সাথে কাজ করবে highscore)। বিপরীতে, যদি আমরা নিজেকে অনেকগুলি রূপান্তর করতে পাই বা findএকাধিক প্রকারের জন্য একই ফাংশন / পদ্ধতি (উদাহরণস্বরূপ ) লিখি, তবে এটি আমাদের
লক্ষণগুলি

1

আমি FindByID এর মতো সুস্পষ্ট ঘোষণার পক্ষে ভোট দেব .... পরিবর্তনের জন্য সফ্টওয়্যার তৈরি করা উচিত। এটি খোলা এবং বন্ধ হওয়া উচিত (SOLID)। সুতরাং ক্লাসটি অনুরূপ ফাইন্ড মেথড যুক্ত করতে খোলা রয়েছে যেমন ফাইন্ডবাইনেম বলি .. ইত্যাদি etc.

তবে ফাইন্ডবাইআইডি বন্ধ রয়েছে এবং এর বাস্তবায়ন ইউনিট পরীক্ষিত।

আমি পূর্বাভাস সহ পদ্ধতিগুলি প্রস্তাব করব না, এটি জেনেরিক পর্যায়ে ভাল। ক্ষেত্রের উপর ভিত্তি করে কী (বাইআইডি) আপনার সম্পূর্ণ ভিন্ন পদ্ধতি রয়েছে।


0

আমি অবাক হয়েছি যে কেউ নীচের মতো কোনও প্রাকটিকেট ব্যবহার করার পরামর্শ দেয়নি:

User Find(Predicate<User> predicate)

এই পদ্ধতির সাহায্যে আপনি কেবল আপনার এপিআই এর পৃষ্ঠকেই হ্রাস করবেন না এটি ব্যবহারকারীর আরও নিয়ন্ত্রণ প্রদান করুন।

যদি এটি পর্যাপ্ত না হয় তবে আপনি সর্বদা এটি আপনার প্রয়োজনগুলিতে প্রসারিত করতে পারেন।


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