কোনও পদ্ধতিতে কি যুক্তিগুলি ক্ষমা করা উচিত? [বন্ধ]


21

মনে করুন আমাদের কাছে এমন একটি পদ্ধতি রয়েছে foo(String bar)যা কেবলমাত্র স্ট্রিংগুলিতে কাজ করে যা নির্দিষ্ট মানদণ্ডগুলি পূরণ করে; উদাহরণস্বরূপ, এটি ছোট হাতের অক্ষর হতে হবে, খালি থাকতে হবে না বা কেবল শ্বেতস্থান থাকতে হবে এবং অবশ্যই প্যাটার্নটির সাথে মেলে [a-z0-9-_./@]+। পদ্ধতির জন্য ডকুমেন্টেশন এই মানদণ্ডগুলি উল্লেখ করে।

পদ্ধতিটি কি এই মানদণ্ড থেকে কোনও এবং সমস্ত বিচ্যুতি প্রত্যাখ্যান করে, বা পদ্ধতিটি কিছু মানদণ্ড সম্পর্কে আরও ক্ষমা করা উচিত? উদাহরণস্বরূপ, যদি প্রাথমিক পদ্ধতিটি হয়

public void foo(String bar) {
    if (bar == null) {
        throw new IllegalArgumentException("bar must not be null");
    }
    if (!bar.matches(BAR_PATTERN_STRING)) {
        throw new IllegalArgumentException("bar must match pattern: " + BAR_PATTERN_STRING);
    }
    this.bar = bar;
}

এবং দ্বিতীয় ক্ষমা পদ্ধতি হল

public void foo(String bar) {
    if (bar == null) {
        throw new IllegalArgumentException("bar must not be null");
    }
    if (!bar.matches(BAR_PATTERN_STRING)) {
        bar = bar.toLowerCase().trim().replaceAll(" ", "_");
        if (!bar.matches(BAR_PATTERN_STRING) {
            throw new IllegalArgumentException("bar must match pattern: " + BAR_PATTERN_STRING);
        }
    }
    this.bar = bar;
}

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

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


1
এটি সম্ভবত আপনার ব্যবহারের ক্ষেত্রে খুব বেশি নির্ভর করে। হয় একটি যুক্তিসঙ্গত হতে পারে, এবং আমি এমনকি এমন ক্লাস দেখেছি যা উভয় পদ্ধতি সরবরাহ করে এবং ব্যবহারকারীকে সিদ্ধান্ত দেয়। এই পদ্ধতিটি / শ্রেণি / ক্ষেত্রটি কী করণীয় তা কী আপনি ব্যাখ্যা করতে পারেন, তাই আমরা কিছু বাস্তব পরামর্শ দিতে পারি?
Ixrec

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

7
আপনি তর্ক করতে পারেন যে উদ্বেগকে আলাদা করে বলছে যে প্রয়োজন হলে আপনার একটি কঠোর fooফাংশন থাকা উচিত যা এটি যুক্তিগুলি গ্রহণ করে তাতে কঠোরতা থাকতে হবে এবং একটি দ্বিতীয় সহায়ক ফাংশন থাকতে হবে যা একটি যুক্তিকে "পরিষ্কার" করার চেষ্টা করতে পারে foo। এই পদ্ধতিতে, প্রতিটি পদ্ধতির নিজস্ব কাজ কম হয় এবং এগুলি আরও পরিষ্কারভাবে পরিচালনা এবং সংহত করতে পারে। যদি সেই রুটে নেমে যাওয়া হয় তবে এটি সম্ভবত ব্যতিক্রম-ভারী নকশা থেকে সরে যেতে সহায়ক হবে; আপনি Optionalপরিবর্তে এর মতো কিছু ব্যবহার করতে পারেন , এবং তারপরে প্রয়োজনীয় ক্রিয়াকলাপগুলি ব্যর্থতা ফেলবে foo
gnskn

1
এটি "কেউ আমার প্রতি অন্যায় করেছে, আমি কি তাদের ক্ষমা করব?" স্পষ্টতই এমন পরিস্থিতি রয়েছে যেখানে এক বা অন্যটি উপযুক্ত appropriate প্রোগ্রামিং মানব সম্পর্কের মতো জটিল নাও হতে পারে তবে এটি অবশ্যই জটিল যে এই জাতীয় কম্বল প্রেসক্রিপশন কাজ করে না।
কিলিয়ান ফুট

2
@ বোগগিন আমি আপনাকে দৃ .়তা নীতি পুনর্বিবেচনার দিকেও নির্দেশ করব । অসুবিধাটি তখন আসে যখন আপনাকে বাস্তবায়নটি প্রসারিত করতে হবে এবং ক্ষমাশীল প্রয়োগটি প্রসারিত বাস্তবায়নের সাথে একটি দ্ব্যর্থক মামলার দিকে নিয়ে যায়।

উত্তর:


47

আপনার পদ্ধতিটি যা বলে তা যা করা উচিত তা করা উচিত।

এটি ত্রুটিগুলি ব্যবহার থেকে এবং পরবর্তীকালে আচরণ পরিবর্তনকারীদের থেকে বাধা দেয়। এটি সময় সাশ্রয় করে কারণ রক্ষণাবেক্ষণকারীদের কী চলছে তা নির্ধারণ করার জন্য যতটা সময় ব্যয় করতে হবে না।

এটি বলেছিল, যদি সংজ্ঞায়িত যুক্তিটি ব্যবহারকারী বান্ধব না হয় তবে সম্ভবত এটি উন্নত করা উচিত।


8
এই চাবি। যদি আপনার পদ্ধতিটি যা বলে ঠিক ঠিক সেভাবে করে তবে আপনার পদ্ধতিটি ব্যবহার করে কোডার তাদের নির্দিষ্ট ব্যবহারের ক্ষেত্রে ক্ষতিপূরণ দেবে। কখনও কখনও পদ্ধতিটির সাথে অবাঁধা কিছু করবেন না কারণ আপনি মনে করেন এটি কার্যকর। আপনার যদি এটি পরিবর্তন করতে হয় তবে একটি ধারক লিখুন বা ডকুমেন্টেশন পরিবর্তন করুন।
নেলসন

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

20

কয়েকটি পয়েন্ট রয়েছে:

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

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


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



15

একটি পদ্ধতির আচরণ পরিষ্কার কাট, স্বজ্ঞাত, অনুমানযোগ্য এবং সহজ হওয়া উচিত। সাধারণভাবে, একজন কলারের ইনপুটটিতে অতিরিক্ত প্রসেসিং করতে আমাদের খুব দ্বিধা করা উচিত । কলকারীটি অনিচ্ছাকৃতভাবে কী পরিকল্পনা করেছিল তা নিয়ে এ জাতীয় অনুমানগুলি অনাকাঙ্ক্ষিত আচরণের জন্ম দেয় edge ফাইল পাথ যোগদানের মতই একটি অপারেশন বিবেচনা করুন। অনেকগুলি (বা সম্ভবত বেশিরভাগ) ফাইল পাথের যোগদানের ক্রিয়াকলাপগুলি নিঃশব্দে কোনও পূর্ববর্তী পাথ বাতিল করে দেয় যদি যোগ দেওয়া পথগুলির মধ্যে একটিতে শিকড় উপস্থিত হয়! উদাহরণস্বরূপ, এর সাথে /abc/xyzযোগদানের /evilফলস্বরূপ ন্যায়বিচার হবে /evil। আমি যখন ফাইলের পথে যোগ দেই তখন আমার উদ্দেশ্যটি প্রায় কখনও তা নয়, তবে কোনও ইন্টারফেস নেই যা এইভাবে আচরণ করে না , তাই আমাকে বাগুল থাকতে হবে বা এই ক্ষেত্রে অতিরিক্ত কোড লিখতে বাধ্য করতে হবে।

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

  • কোনও প্রাক প্রসেসিং ছাড়াই কাঁচা কার্যকারিতা।
  • নিজে থেকেই প্রিপ্রোসেসিং পদক্ষেপ ।
  • কাঁচা কার্যকারিতা এবং প্রাকপ্রসেসিংয়ের সংমিশ্রণ।

শেষটি alচ্ছিক; আপনার কেবলমাত্র এটি সরবরাহ করা উচিত যদি বিপুল সংখ্যক কলগুলি এটি ব্যবহার করে।

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


2
অনুমানযোগ্য জন্য +1। এবং আরও একটি সহজ +1 (আমি চাই)। আমি বরং আমার ভুলগুলিকে আড়াল করার চেষ্টা করার চেয়ে আপনি আমাকে চিহ্নিত করতে এবং সংশোধন করতে সহায়তা করবেন।
জন এম গ্যান্ট

4

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

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

অন্যদিকে, যদি ইনপুটটি এসেছিল, বলুন, প্রযুক্তিগত লোকেরা সমবেত করা সম্পত্তিগুলির ফাইলগুলি, যারা বুঝতে হবে যে "Fred Mertz" != "FredMertz", আমি ম্যাচিংয়ের স্ট্রিকেটার তৈরির জন্য আরও বেশি আগ্রহী এবং উন্নয়নের ব্যয়টি বাঁচাতে চাই।

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


3

আপনি যে প্রসঙ্গটি থেকে এই প্রশ্নটি আসে তার কয়েকটি উল্লেখ করুন।

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

যদি আপনি ব্যবহারকারীর ডাটাবেস থেকে আসা ডেটাটিকে আরও কিছু ক্ষমা করার পদ্ধতিতে রূপান্তর করতে চান তবে সেই কার্যকারিতাটিকে একটি পৃথক রূপান্তর পদ্ধতিতে রাখুন এবং কার্যকারিতাটি এটির সাথে নথিভুক্ত করেছেন

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

এখানে বড় জোর স্পষ্টতা এবং কোড কী করে তা নথিভুক্ত করা


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