আমাদের কি ওভারলোডেড পদ্ধতিগুলির নাম পরিবর্তন করা উচিত?


14

এই পদ্ধতিগুলি সমন্বিত একটি ইন্টারফেস ধরে নিন:

Car find(long id);

List<Car> find(String model);

তাদের নাম বদলে রাখাই কি আরও ভাল?

Car findById(long id);

List findByModel(String model);

প্রকৃতপক্ষে, যে কোনও বিকাশকারী যারা এই এপিআই ব্যবহার করেন তাদের প্রাথমিক find()পদ্ধতির সম্ভাব্য যুক্তিগুলি জানার জন্য ইন্টারফেসটি দেখার প্রয়োজন হবে না ।

সুতরাং আমার প্রশ্নটি আরও সাধারণ: কোডটি ওভারলোডেড পদ্ধতিগুলি ব্যবহারের সুবিধা কী কারণে এটি পাঠযোগ্যতা হ্রাস করে?


4
যেহেতু আপনি সামঞ্জস্যপূর্ণ ততক্ষণ পদ্ধতি গ্রহণযোগ্য।
ChrisF

একটি পদ্ধতি ওভারলোডিং ও ওভাররাইডের মধ্যে একটি সম্পর্ক রয়েছে। তবে এই নিবন্ধটি আপনার পরামর্শের পক্ষে - এটি আগ্রহী হতে পারে: roseindia.net/javatutorials/…
NoChance

উত্তর:


23

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

এই বলে যে, আপনি যদি এটি সম্পর্কে কিছু করতে যাচ্ছেন তবে আমি এই অনুশীলনটি অনুসরণ করব:

  • ওভারলোড যদি ...

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

  • একটি আলাদা নাম ব্যবহার করুন ...

    পদ্ধতিগুলি উল্লেখযোগ্যভাবে বিভিন্ন জিনিস করে বা বিভিন্ন আউটপুট (যেমন আপনার ক্ষেত্রে) ফেরত দেয়। কেউ যদি ডাটাবেস অ্যাক্সেস করে এবং একটি না করে তবে আপনি আলাদা নাম ব্যবহার করার কথা বিবেচনা করতে পারেন।

    তদতিরিক্ত, যদি ফেরত পাঠানো টাইপটি আলাদা হয় তবে আমি ক্রিয়াটিও পরিবর্তিত করে তা নির্দেশ করেছিলাম:

    Car findById(long id);
    
    List findAllByModel(String model);
    

3
এফডব্লিউআইডাব্লু, আমি এটিকে আরও দৃ strongly়তার সাথে বলব: "পদ্ধতিগুলি ঠিক একই চুক্তি পালন করে ..." অর্থাৎ আর্গুমেন্টের ধরণ / গণনা কোনও বিষয় নয় - ফাংশন কলটির শব্দার্থবিজ্ঞান নির্বিশেষে অভিন্ন। যদি আর্গুমেন্টের ধরণ / গণনা বিষয়টি বিবেচনা করে তবে আপনার ওভারলোড করা উচিত নয়।
এমএমসিসিসি

4

আমি প্রতিটি ক্ষেত্রেই আলাদা নাম ব্যবহার করার পরামর্শ দেব। এটি সম্ভব যে ভবিষ্যতে কোনও সময় আপনি এর List<Car> findByMake(String make)বিপরীতে অন্য একটি পদ্ধতি যুক্ত করতে চান List<Car> findByModel(String model)। তাই হঠাৎ করে, সমস্ত কিছু বলা কল্পনা করা findবন্ধ করে দেয়। আপনার নামগুলিও অজান্তে ভুলভাবে ব্যবহার করার সম্ভাবনা কম থাকে, যদি তাদের নামগুলি কীভাবে ব্যবহার করা উচিত সে সম্পর্কে আরও তথ্য দেয়।


1
ন্যায়সঙ্গতভাবে, কার্যকারিতাটি আরও স্পষ্টভাবে বস্তুগুলির দ্বারা প্রতিনিধিত্ব করা হলে: এটি কোনও ইস্যুর মতো হবে না: find(Make val)এবং find(Model val)। তারপরে, সুবিধার পদ্ধতিগুলি যেমন findByMake(String val)তারা আসলে কী করছে তা আরও স্পষ্ট হবে। সর্বোপরি, একটি Stringহয় কোনও মেক বা মডেল নয়, সুতরাং পদ্ধতিটি এটি কী করছে তা ব্যাখ্যা করা উচিত।
নিকোল

4

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

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

সুতরাং এটি করছেন:

void MyMethod(int param1, int param2 = 10)
{
    ...
}

এটি করা থেকে আপনাকে বাঁচায়:

void MyMethod(int param1)
{
    MyMethod(param1, Param2Default);
}

void MyMethod(int param1, int param2)
{
    ....
}

যা আরও পাঠযোগ্য, সত্যই এটি আপনার কাছে নেমে আসে। ব্যক্তিগতভাবে আমি দ্বিতীয় বিকল্পটি পছন্দ করি, বিশেষত যখন প্যারামিটারের তালিকাটি আরও দীর্ঘ হয় তবে আমি মনে করি আপনি এতক্ষণ আপনার API এর সাথে সামঞ্জস্যপূর্ণ হওয়ার কারণে এটি এতটা গুরুত্বপূর্ণ নয়।

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

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

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


0

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

ধরুন কলিং ফাংশনটি কোনও প্যারামিটার হিসাবে অনুসন্ধান অনুসন্ধান পেয়েছে এবং কল করার আগে এবং / অথবা পরে কিছু অন্যান্য প্রক্রিয়াজাত করে find

void tryToSellCars(String which) {
    /* grab an airhorn, inflatable tube guy... */
    List<Car> cars = find(which);
    /* expound virtues of each car in detail... */
}

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

void tryToSellCar(CarQuery which) {
    /* grab airhorn, inflate tube guy... */
    List<Car> cars = find(which)
    /* expound virtues of each car in detail... */
}

আপনি যদি বাস্তবায়ন করেন findByIdএবং findByQueryObjectআলাদা করে রাখেন, আপনাকে এই পরিবর্তনটি করতে প্রতিটি কল সন্ধান করতে হবে। উদাহরণস্বরূপ, আমি কেবল একটি শব্দ পরিবর্তন করেছি এবং আমার কাজ শেষ হয়েছিল।


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